All too often, Iโ€™ve encountered code that uses a pattern because the developer felt he should use a pattern there, not because he needed the pattern.

Not every developer understands that patterns add complexity to a solution. ...

The important concept to understand is that Design Patterns are descriptive not prescriptive. They arenโ€™t intended to instruct how one should design a system, but merely describe successful designs that have worked in the past for common problems.

Welcome to where I work right now.  In a post that links, Haack gets waaay too close to home describing what this can feel like.

If you need to instantiate a factory, implement an adapter class and use a bridge to the toilet just to [go No. 2], then you probably live with a developer with a premature generalization problem.


What I've heard to explain mindless pattern usage is that many of our folks don't understand when you've gone from code that doesn't deserve major abstraction to code that does.  While ultimately that's a hiring problem (you don't have coders competent enough to know how to factor their code), that fact doesn't help you solve the problems your current staff already has.

That's a tough quandary -- do you beat your head against the wall trying to teach those who seemingly can't be taught, spending yet more time making sure they go back to clean up their messes as they slog along -- or do you simply force them to follow the patterns all... the... time?

I think you have to try to teach folks, and if they continually can't handle refactoring, you have a reason to let them go.  It's expensive to fire and hire, but it's got to be more expensive to keep using folks who can't code.

Great quote from Erich Gamma in that same post:

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.

So far, I love this series of posts by Haack...

Design Patterns Isnโ€™t [sic] a Golden Hammer
Avoid Premature Generalization
Avoid Premature Standardization

He apparently also has some posts on avoiding premature optimization.  I'm just starting in on reading the series, and will probably feel compelled to blog about them a few more times...

Labels: , ,