Bob, How would you introduce Design Patterns into any book or course teaching an OO language ? Has GoF becomme less relevant as other languages replace C/C++ ? Anti-Patterns also seem to have their place.
Here's an approach: 1: Try/Discover the Anti-Pattern first (occurs naturally, so it isn't that difficult to find) 2: Talk about the faults/risks. 3: Introduce the correct Design Patterns.
Would you agree ? regards [ September 11, 2003: Message edited by: HS Thomas ]
Originally posted by HS Thomas: Bob, How would you introduce Design Patterns into any book or course teaching an OO language ?
By example. Set up a design problem and then show how different patterns resolve the problem in different ways. GOF is a relevant book, but not a tutorial. I've tried to take a more tutorial stance in "Agile Software Development: Principles, Patterns, and Practices" (http://www.objectmentor.com/PPP).
I see you can move from Anti-Pattern to Pattern to Anti-Pattern as your problem evolves. And back to Pattern again. Thanks. And that there is not just a single Design Pattern for a problem. I think there is an effort to list Design Patterns by problem. Motivation, Consequences, Pattern. People tend to find the motivation that fits the problem and call that Design. Would you agree to disagree with that approach . Thanks
What you should realise is that most solutions are best implemented by having several patterns work together. That is, unless you're talking about an extremely small very finegrained approach instead of taking a highlevel overview of a module. You might have a factory implemented as a singleton for example.
We don't *use* patterns. We don't face design problems and then look through a book to find the pattern that solves the problem. Rather, we work towards the solution of the problem until that solution begins to look like one of the patterns. When we are convinced that the correspondence is close enough, we change the names of the classes and variables to conform to the pattern. This helps others who read the code to recognize what is going on. If you see a class named ClockObserver, you can be reasonably sure that is is part of the Observer pattern. If you see ModemDecorator or ParseNodeVisitor, you know what to expect. This is the true power of patterns. Patterns are more for the reader, than for the designer. The designer finds that he is approaching a pattern, so to help the readers of his code, he makes that code conform to the pattern.
That is what a good designer does, but many will decide first what pattern to use then religiously use them whether that choice was correct or no. And most design books teach us to work that way, by placing the pattern central in the design and the actual code as being somehow relegated to a mere inconvenience obscuring the pattern from its glory.