For example, (just a few examples, books could probably be written on this
subject),
You actually wrote book in your post :)
j.c.wichman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
You are probably going to hear this a lot: it depends.
You'll find a lot of people doing 1, you'll find a lot doing 2... 3 4 5
6 etc.
For example, (just a few examples, books could probably be written on this
subject), an animation of a car driving down a road, sliding, going
through
corners etc:
- could be an animation on a timeline
- could be coded using positions, vectors etc
- could be coded using displacements maps
- could be coded by recording all the positions of an object during a
tween
and playing it back (altered or not)
- ..?
Which is the most appropriate to your project? Do the animations have to
be
very specific, are they updated a lot? When they do have to be updated, do
you have to go to heaps of code, just becoz u have a timelinephobia? Etc
etc
These are all questions u could ask yourself. I took the example of an
animation, but you could ask these kinds of things for databases as well
(which database? One or more? Do we have to switch between dbs? Etc).
No matter what I think u should be able to answer the 'why?' questions for
yourself. Why do I do it like this?
For example, why do I use a timeline animation in case A, and a coded
animation in case B?
Well because in case A the animation is well defined and very simple, and
I
want to be able to update it quickly, in case B the animation is very
complex, it depends on factors like gravity and the like, and I don't want
to go there timeline wise.
What? So you use different options at the same time! Sometimes yes ;). The
beauty of grey ;). Note that I don't mean to sound like a know-it-all,
because the issues you raised are issues I think a lot of us struggle with
everyday (I know I do!), so I don't claim to have all the wisdom, I'll
just
try to give you one view (my view) of the story.
Anywayz, back to the example...
So different options at the same time... The animation example is taken
from
real life, from a project I'm working on as we speak. I always try to
think
of it as, if I don't have a clue about HOW I'm going to do it (99%) I stop
and remind myself of the WHAT (as I should do all the time :)). So.. We
have
an abstraction: an Animation class.
What does it do? It plays, it stops, etc. How? No clue, an Animation
subclass could be an animation built on top of Fuse, an movieclip with a
timeline, a handwritten piece of code, I don't care, as long as it plays
and
stops and
So I don't think this falls within either option 1 or 2, but within option
x... And I wish I knew how to describe option X :).
With regard to design patterns and MVC... First of all, I think design
patterns are a means to an end. Design patterns have multiple
goals/attributes:
- they solve (part of) a difficult architectural problem for you
- they increase reuse, robustness, maintainability
- they help documentation your code, instead of describing class a,b,c,d
you
say, I used this pattern, and these classes play these roles
- they might increase the complexity of your application
Looking at the second point, reuse, robustness etc, the first patterns
that
come to mind, might not even be considered as patterns.. Low coupling,
high
cohesion, that kind of thing. Even without learning dozens of patterns, a
lot of times the questions are as simple as:
- if at one point I want to incorporate this into my programm, what
happens?
- if I pull this string, what happens?
- if ...
- if ..
- if .
If the answers to these kind of questions are: well, then I'd have to
throw
it all away and start over, some of the basic patterns may have been
overlooked. On the other hand the answer might as well be: listen, you are
trying to fit a square peg into a round hole, you are treading outside of
the scope this code was meant to handle. One more note on design patterns,
one of the most difficult things I encountered is that sometimes these
patterns have not different goals but OPPOSING goals, one might increase
reuse but break encapsulation, one might improve encapsulation but break
reuse etc.
With regard to the MVC pattern, I often collapse the controller and view.
Most important for me are clear cut responsibilities, a model with no
dependencies on the view. If another view has to be created, I might
refactor my collapsed view/controller. Lot of times there is even
discussion
on whether it IS collapsed or not. For example 2 options:
- I write a movieclip, put a few components in it(view) , and write a
class
(controller) and connect it to the movieclip in the property dialog. Is it
collapsed?
- I write a class which creates all the components by code. (this might be
clearer)
If I am certain up front there will be multiple views, I might put more
time
into the
