That's a good response Alan.
There are still some things that I would like to reply to specifically.
> Ugh, I haven't finished reading the GOF's book.
As you read the book, I would suggest refering to it for your current
projects. The book is accually designed to be easily used as a refrence,
you'll most likely have to consult it even when you're finished.
> I think I need brain vitamins. Could you suggest one? ;)
Haha, eating nuts and seeds is a great way of maintaining a healthy level of
brain glucose ;)
> In your experience, are patterns useful in small projects?
Abstract from computing, it's important to realize that we organize
complexities from existing premises; more complex patterns are designed
using lesser complex patterns. The lesser complex patterns are so
fundamental that we often don't even recognize them. I am certain that you
are using patterns in your small projects. Delegations are a good example,
simply because no system, computer or other, is able to function without the
ability to route information.
> You know, I've
> been learning patterns through
> "C#.NET Design Patterns" and so far, to me, patterns only useful in big
> projects (in small ones, it might make
> things overcomplicated). Correct me if I'm wrong, please.
You're correct, using the wrong pattern for a problem may over complicate a
system. It's important to properly select your patterns. The GOF book will
help you understand which pattern, and sometimes pattern compsite, will best
solve a problem.
Take care,
M.
On 2/3/06, Alan MacDougall <[EMAIL PROTECTED]> wrote:
>
>
>
> >
> >In your experience, are patterns useful in small projects? You know, I've
> >been learning patterns through
> >"C#.NET Design Patterns" and so far, to me, patterns only useful in big
> >projects (in small ones, it might make
> >things overcomplicated). Correct me if I'm wrong, please.
> >
> >
> Some patterns are only useful in big projects. But remember, patterns
> exist to solve problems -- some problems only occur in big applications,
> but some occur all the time.
>
> Let's take a simple example that could occur in any size of project,
> especially a Flash one: you want a particular object to react to user
> input. But you want it to react differently depending on the program
> state. For instance, maybe the user clicks an Erase tool, then clicks a
> drawing area -- that's different from if he clicks a Brush tool.
>
> One solution would be to write "if (tool == erase) { doSomething } else
> if (tool == brush) { doSomething Else }"... but you can see how that
> would turn your program into a horrible mess if each tool has
> complicated behavior.
>
> Instead, look up the State pattern in your GOF book. See? A design
> pattern that can have many uses, both large and small.
>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
