A rootin', tootin' new article entitled "Evil Patterns", written by Paul Wheaton hisself, appears in the latest issue of the JavaRanch Journal. You kin check out that there article here. Y'all have anything to say about it? Say it right in this thread!

I couldn't have said it any better myself! All too often I look at the design of a software project and say to myself "Why on earth are they using this pattern here? It would be much simpler to do it this way..."

In one project, I compared the over-use of design patterns to a Knight. A knight shrouded in extreme armor may be invulnerable to swords or arrows, but what good is he if he can't move or maneuver? That's what software becomes when you load it up with unecessary patterns. It may be strong and robust, but most of the times, its overly complicated and performance degreades.

Just my thoughts

 

I think that any pattern being used in an application could/should(/must!) be trumped by "the simplest thing that could possibly work."

Back in 2002 Scott Ambler warned in his book Agile Modeling to Apply Patterns Gently (page 62, referencing both Joshua Kerievsky's "Patterns and XP. Extreme Programming Examined"; 2001, pp.207-220 and Martin Fowler's Is Design Dead: Patterns and XP (2001)).

It's nothing new that most people are a bit overzealous with their "new" toys - though Design Patterns: Elements of Reusable Object-Oriented Software (Jan 1995!) has been around for a while - but it seems it took something like Head First Design Patterns (Oct. 2004) to make design patterns generally accessible and "really popular". Maybe now design patterns can finally become "just" yet another tool that is only applied when appropriate.
There is no need to introduce patterns pre-maturely as they can be introduced at a later point of time when the benefits are clear.
Refactoring to Patterns (Aug. 2004) Joshua Kerievsky
Working Effectively with Legacy Code (Sep. 2004) Michael Feathers
[ March 22, 2006: Message edited by: Peer Reynders ]

I was one stage over zealous too. especially when I started learning design patterns. In my view, learning a design pattern is easy, but more difficult part is to identify when and where they can be effectively applied.

Thanks, Paul, I felt like you were channelling my own thoughts there.

The only point I'd add is the 'Pattern as a weapon' ie "I know more patterns than you, so rather than using them as an aid to communication I'll deluge you till you give up and walk away". I've seen this a couple of times

 

Originally posted by David O'Meara:
Thanks, Paul, I felt like you were channelling my own thoughts there.

The only point I'd add is the 'Pattern as a weapon' ie "I know more patterns than you, so rather than using them as an aid to communication I'll deluge you till you give up and walk away". I've seen this a couple of times

Or, my favorite, Since I am talking louder, then I am right and you should use the Patterns that I want to use.

Mark

Hi,

I tend to disagree with the prevous posters (and the article). Most of the software I've seen (which is a subset only, of course) didn't suffer from too much patterns, it was always the opposite. Really creepy code that was very difficult to maintain, especially after some changes. A well-used(!) pattern would have done wonders to the code's structure.

I think I've seen one project that was too overloaded with patterns. I've seen far more projects that needed some patterns applied to reduce developer ramp up time. "The simplest thing that could possibly work" - I definately wouldn't go that far. Patterns aren't simple until you know them, then they allow you to make generalizations that should be true - IE this is a DAO I expect to find code here to load/save/update an object.

A newbie will tell you the simplest thing is one giant class file - like the 800 line web service I got the source to this week (inline JDBC and other web service calls).

I also tend to disagree with the "don't get suckered by some putz". Anyone can have a good idea, don't wait until "the greater minds" tell you something is a good idea if you find an idea and like it. Play with, learn it, make it better.

Just my 2 cents from "some putz"

I used to love design patterns, but it seems to often often into an excuse for documentation ...

- Problem 1 :

The vocab bit can break down as one persons pattern is not another persons ...
I had an argument with a web developer who claimed they didn't need to document their code as is was MVC and I should therefore know that and not require any , it was actually Sun's specialisation of MVC, so I pointed this out by showing them the GoF book only to be told I was of course wrong and that book was in error ;-) "That's not a MVC"

Problem 2 :

Another instance ... some one recently claimed I hadn't followed their pattern on a project, I replied that I wasn't aware there was one, apparently I should have inferred it again used as an excuse for the omission of the simplest of comments.

Just for anyone else listening a new design pattern with out documentation is not a design pattern it's a cryptic splodge :-(

 

Chris Hurst wrote:

- Problem 1 :

The vocab bit can break down as one persons pattern is not another persons ...
I had an argument with a web developer who claimed they didn't need to document their code as is was MVC and I should therefore know that and not require any , it was actually Sun's specialisation of MVC, so I pointed this out by showing them the GoF book only to be told I was of course wrong and that book was in error ;-) "That's not a MVC"

The problem with this story is that MVC is not a GoF pattern. A lot of people claim it's not a pattern at all.

 

Mike Himstead wrote:I tend to disagree with the prevous posters (and the article). Most of the software I've seen (which is a subset only, of course) didn't suffer from too much patterns, it was always the opposite. Really creepy code that was very difficult to maintain, especially after some changes. A well-used(!) pattern would have done wonders to the code's structure.

This has also been my experience. I have seen some really bad abuse of patterns, usually in an attempt to look good to management and other less-knowledgeable developers. However, the beast I have always had to fight was the OO code that was not based upon good understanding of OO principles and lacked any use of design patterns. The mis-use of a design pattern is can often be fixed with some effort but fixing a C program written in Java is often a fight with an ugly beast.

 

Michael Valentino wrote:A knight shrouded in extreme armor may be invulnerable to swords or arrows, but what good is he if he can't move or maneuver?

Off topic but just for the general knowledge: A knight was not invulnerable to swords or arrows and they actually were very maneuverable. Same weight load as a modern soldier except that the load was spread over the whole body, not just the back. Movies and TV are a bad place to learn history.

I'm glad people write articles like this. It serves as a warning to addicts like myself that too much of a good thing can kill you. I am currently in a debate with myself over the balance of design patterns vs. simple (yet ugly) solutions. For example, I HATE redundant code. I can't stand writing the same thing twice and then having to fix it twice when requirements change. Patterns help you eliminate redundancy. That's one of the reasons I became infatuated with them. But there is a cost in overhead and understandability (e.g., defining and implementing interfaces, wiring in Spring, dividing code up into smaller modules). It makes no sense to implement the Strategy pattern to save a few lines of redundant code. You more than pay for it in overhead. So I find myself constantly trying to balance the tradeoffs, wishing there was a way I could eliminate the redundancy while not having the overhead. But I don't think there is a silver bullet answer. The reality is this: life ain't always pretty, and sometimes code ain't either.

It's called engineering.

Bear - was that at me? If so, not sure how you meant it.

Was the not clear enough? Engineering is the art of balancing the benefits and drawbacks of any approach.

Gotcha - good definition.

One of the patterns I'm sick to death of is the Template pattern. There are way too many in-house, home-grown frameworks in the Java web application space that excessively use this pattern. I mean it's so hard to follow the logic around because you keep jumping between sub-classes and super classes. Which methods do I override, and when etc... And to top it all, most of these frameworks are poorly documented, which makes it doubly hard to understand them, especially for the new guys on the team. I think there are good examples of its usage also (Spring) but they come with excellent documentation. Although, the fact that it requires heavy documentation to simply start using it should be a sign that it could be done better.

It makes me wonder what are some of the other ways of designing through which these problems can be avoided.

Just chiming in...

 

Robin Sharma wrote:I mean it's so hard to follow the logic around because you keep jumping between sub-classes and super classes.

If you are jumping between super and sub, you may not be implementing the pattern correctly. It should always be one-directional (Don't call us, we'll call you principle), where the super contains the general algorithm and calls through abstract method for variations to that algorithm. Its the same way for the strategy pattern, just compositional instead of inheritance. Both these patterns allow implementation of Inversion of Control. So perhaps the issue is that you've seen abuses of the template method pattern.

i would rather think of how the future will affect my design when creating a system. Then tell my self, "Wow, i never imagined that i have a strategy pattern here!"

 

All too often I look at the design of a software project and say to myself "Why on earth are they using this pattern here? It would be much simpler to do it this way..."

That strikes me as a comment on how patterns are used, rather than a condemnation of them in general.

As Einstein said (sort of) "everything should be as simple as possible; but no simpler" and, while I'm all in favour of dumb programming, Paul's article (or at least the digest I found) struck me as a rather Luddite exhortation to 'simplicity'.

Patterns are tools; nothing more, nothing less. If you don't like 'em, don't use 'em; but you'll be missing out on a lot of acquired knowledge and will probably end up re-inventing the wheel in the process.

Me, I just got a new copy of GoF about two months ago and am thoroughly enjoying re-reading it.

Winston