Design Patterns discussion

[jkost AT ergoway.gr]

Hi Justin,

the way to think about applying design patterns is mainly to remember 
what sort
of problem each pattern is supposed to solve. E.g. the Observer pattern allows
for multiple observers to be notified by a subject, when the latter's 
state has
changed, in a loosely coupled way. So, if you want your Note(s) and 
Reminder(s)
to be notified when something has changed in your Calendar object, then yes,
Observer is a good pattern to use in this case. Then, you draw your class
diagram for your objects, based on the design pattern's class diagram and try
to implement it in your programming language. Sometimes, programming languages
provide support for some design patterns; e.g. Java has the Observable and
Observer classes, C# may have something similar.

Another example; suppose you have a case where e.g. a Reminder is a 
kind of Note
and a Note can contain a Reminder and a Note (not your case, but just to give
another example) then you would consider the Composite pattern (think of it as
the directory structure, where each directory can contain directories or
files).

Anyway, apart from the GoF book which you should have read already, 
"Head First
Design patterns" from O'Reilly is an excellent book you should read. "Design
Patterns Explained" could be of some help too.

There are also a couple of books on C# design patterns as far as I 'm 
aware of.

So, to recap, you only need to remember what sort of problem each 
design pattern
solves; if you find a match of your problem that can be solved by a design
pattern, then try it. But, do not overdo it, and always document what you are
doing for others to be able to understand. Do not hesitate to add to your
javadoc e.g. that this is the implementation of the Observer pattern, where
Calendar is your subject and Note and Reminder are the observers. A class
diagram always helps.
After you apply a few patterns you 'll have gained valuable experience to be
able to tell whether to use a specific design pattern for a case or not.

Hope this helps.

John.

Quoting David Rosenstrauch 
<darose AT darose.net>:

> A. Rick Anderson wrote:
> > Justin Daubenmire wrote:
> >
> > > Thanks Emilio for the advice.
> > >  Yeah, I can see your and Ray's point of patterns not being needed but
> > > only when a problem surfaces that merits it.
> > >  I'll need to keep this in mind as I try to learn/apply them.
> > >  Also, thanks for the book suggestion - I will have to read that book.
> > >  Does anyone have any other book suggestions?
> >
> > When JUnit first came out, they published a "cookbook" on the design and
> > implementation.  It may have mutated since into something different,
> > IMHO, the original JUnit cookbook is one of the best, most succinct
> > examples of using and applying patterns.
>
>
> Found here, I think:
>
> http://junit.sourceforge.net/doc/cookstour/cookstour.htm
>
>
> The Java HotDraw project is also a good patterns tutorial:
>
> http://www.jhotdraw.org/
>
>
> HTH,
>
> DR
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns