Why Design Patterns are useful
I was thinking today about Design Patterns and I not only do I find them interesting but they are very useful as well. I thought I would note down the reasons why
1. A tried and tested solution to a common problem
2. Other programmers can understand what you are talking about and if they don't understand then there is information out there
3. Examples of code to aspire to
4. A good way to learn
5. They aren't the solution to every problem but they can still help you
1. What you get with Design Patterns is a lot of common problems and then a lot of common solutions. Not only have you got access to the code but there is also lots of data with detailed explanations to help you understand it. Also the code you see with Design Patterns is not only tried and tested but has gone through numerous interactions.
2. If another programmer also knows about design patterns then you talk about code with complex structures by using a quick word instead of explaining the idea by talking about each class and then drawing uml diagrams etc etc.
3. One of the main reasons I like Design patterns is looking at the code. The code is so lean and mean. I am always amazed that there is just so little of the code and personally it is the type of code I would like to be writing.
4. Reading about design patterns and looking at the code is a good way to learn because there is a lot of Design pattern resources out there, so if you can't understand one persons explanation then you can read another which might be more suited to your learning style.
5. Sometimes using Design patterns is not the best solution because they might be too complex or just not suited to the task at hand. There is a danger that people who have just learnt about Design Patterns go about putting them in the code at every available opportunity. Don't do it. What I find sometimes thought is that looking at various design patterns can give you an idea, you can borrow some of the Design Pattern and apply it to the code you are currently writing or looking at the design patterns might give you an idea of how to structure the code. The examples that accompany Design patterns aren't usually anything like the problem you are looking at but you can always adapt the design patterns into your own creation and who knows you might even create another Design Pattern in the process.
posted by The Hosk at
1:28 pm
6 Comments:
You need to know the common problems that the common solutions can cause.
For example, Singletons:
* Mutable data synchronicity problems.
* Can be hard to change into non-Singletons, depending on how you organise your code. With IoC it isn't such a big issue.
* Technically impossible in Java, due to classloader boundaries. (except Java ME)
* Often implemented in a broken way, look out for 'double-checked locking'.
* Stateful singletons are basically global variables (not really a disadvantage, just pointing out the obvious).
Most documentation that I've seen on patterns is very positives-only.
Let's take another, more useful pattern: Strategy
* Often used instead of an if..else tree or a switch statement, but the compiler can verify switches on enums, i.e., it can tell whether you remembered to include all enum members. It can't tell whether your strategy map included all enum members, or other possible values.
* In Java, the anonymous class verbosity can make strategy harder to understand than the 'imperative' alternatives.
* Visitor (or in other languages, dynamic dispatch), is often better (I haven't worked out when).
Cheers.
By
Ricky Clarkson, at Wed Sept 13, 03:03:00 pm 2006
This is a very good point and well made.
I like to have a balanced look at design patterns. I have seen the singleton 'double checked locking' problem highlighted but not so much your other points.
By
The Hosk, at Wed Sept 13, 05:41:00 pm 2006
To expand on Ricky's comments, I don't think that anyone disputes that the concept of "design patterns" is generally a good one. The issue is with the actual patterns themselves.
The Gang of Four patterns are, for the most part, best characterized as "ways to use or abuse dynamic dispatching in C++". Unfortunately, the easy way to get dynamic dispatching in C++ is to create a polymorphic class structure, and that's the way that the GoF did it. The inescapable consequence was that subclassing and inheritance became widely used in inappropriate places.
I consider the widespread acceptance of the GoF book as the turning point at which OO went awry. Developers quit thinking about the objects and what they represented, and instead concentrated on creating classes with inheritance that would allow all sorts of neat tricks that they could pull with dynamic dispatching. They went back to thinking about coding instead of thinking about designing.
The late John Vlissides, one of the original GoF, wrote a later book called "Pattern Hatching". Although that book was not generally notable, he did observe that much had been learned since the original GoF book was released and that a number of significant problems had been found with some of the patterns - especially Singleton and Visitor. And that was only three years after the GoF book came out; almost another decade has passed since then.
Coincidentally, just the other day Mark Dominus wrote an interesting weblog entry about how design patterns tend to be about circumventing language shortcomings. I'm with Mark… with an occasional exception, almost all "design patterns" are better labeled as "coding patterns".
By
Doug, at Thu Sept 14, 12:22:00 am 2006
Thanks for your comments they have been very interesting. I think you are right that Design Patterns could be used to stop people thinking about Designing a solution themselves.
In some ways Design Patterns could be used to provide a quick fix. On the other hand when I starting reading about Design Patterns they lead me backwards towards the OO design. The reason I like design patterns because they are good examples of code but you appreciate them more once you have studyed some OO techniques. After looking at some Design Patterns I went and read a lot of the ObjectMentor articles.
but I think you have a very valid point because if you didn't investigate the OO techniques and methods then Design Patterns could end up as a bit of a quick fix.
By
The Hosk, at Thu Sept 14, 08:40:00 am 2006
Hosky, I think you might have misunderstood my comment.
I think Design Patterns are a good thing. I don't think that people should reinvent the wheel.
What I object to is that most Design Patterns aren't design patterns, they're coding patterns. They're nothing more than coding idioms for dealing with the limitations of a particular language… not ways of approaching the design of a software system.
If you want some examples of what I consider real design patterns, look at the Domain Neutral Component and its successor, the Streamlined Modeling system. These say that a business domain model consists of components with a totally predictable structure: at the core is an event which occurs at a particular time or a relationship which applies over a particular time period, and associated with that event or relationship is the party who initiated it, the place where the event occurred, items associated with the event, prior events that triggered or enabled this one, and succeeding events that this one triggered or enabled. Do you see any code in there?
The problem that I have with the "coding idioms called design patterns" isn't that they exist—that's great too—but rather that by taking the name "design patterns" they caused the mainstream of OO developers to stop thinking about designing objects and start thinking about coding for dynamic dispatching. When that happened, OO was reduced to being just another coding style and lost its promise of revolutionizing software development.
By
Doug, at Fri Sept 15, 04:30:00 pm 2006
This comment has been removed by a blog administrator.
By
Anonymous, at Sat Nov 25, 05:43:00 am 2006
Post a Comment
<< Home