Eric Gunnerson made an interesting blog post that got me reading a couple of
interviews with Erich
Gamma. My first formal exposure to the GoF book was at a utility company
writing a solution for deregulation. It was a horrible, horrible nightmare of
"Object Exhibitionists and Frameworkitis" and worst of all...it was written in
classic VB! For those of you familiar with VB, it did not support OOP constructs
such as inheritance and overloading. Yeah, you could implement polymorphism with
VB...but overall the type of forced-design-pattern-mania led to a ton of
problems. It baked in a whole lot of functionality that you didn't want from the
framework (if you could call it that). It wrapped wrappers and other
unintelligible things, so it was very slow and made debugging very difficult. It
contained design patterns just for the sake of using design patterns, not to
solve problems. It was written in a non-OO language.
Anyway, I'd like to share a couple of quotes from Erich Gamma that I greatly
appreciated...
"Do not start immediately throwing patterns into a design, but use
them as you go and understand more of the problem. Because of this I
really like to use patterns after the fact, refactoring to patterns. One
comment I saw in a news group just after patterns started to become more
popular was someone claiming that in a particular program they tried to
use all 23 GoF patterns. They said they had failed, because they were
only able to use 20. They hoped the client would call them again to come
back again so maybe they could squeeze in the other 3. Trying to use all
the patterns is a bad thing, because you will end up with synthetic
designs—speculative designs that have flexibility that no one needs.
These days software is too complex. We can't afford to speculate what
else it should do. We need to really focus on what it needs.
That's why I like refactoring to
patterns. People should learn that when they have a particular
kind of problem or code smell, as people call it these days, they can go
to their patterns toolbox to find a solution."
"I duplicate the code once. I duplicate it twice. And then, wow, I
had to duplicate it again. At this point the abstraction process starts.
So, I say, it would be really nice if this class would allow me to plug
in this custom behavior so that I do not have to duplicate the rest."
"When we started exploring frameworks years ago, we had big hopes for
them. We thought the way to create software was to build high-level,
domain-specific frameworks, and then you just customize them and reuse
all the design that is codified into them. That was the reuse nirvana.
Since then, I've gotten a little more realistic, because I have learned
that it's hard to create highly reusable frameworks."
"A lot of the patterns are about extensibility and reusability. When you
really need extensibility, then patterns provide you with a way to
achieve it and this is cool. But when you don't need it, you should keep
your design simple and not add unnecessary levels of indirection."
