Monday, 19 March 2007

Anti Patterns: Don’t ignore them

Why do we love summer? Because, we don’t like winter. Would we ever understand the importance of daylight if there was no night? The universe just wouldn’t be complete if we had patterns and no anti-patterns, would it?

Well, I believe we all know the answers. Let’s elaborate on this thought to find out the “WHAT” and “WHY” of anti-patterns. A design pattern gives the general solution to a recurring problem in a particular context and “an Anti-pattern tells us how to go from a problem to a BAD solution”. [1] When a good pattern is applied by a wrong person, it becomes an Anti-pattern and we document it to avoid the same mistake. "Why on earth would we document a bad solution?" Keep reading...

If there is a bad solution to a problem and it is recurring, wouldn't it be a good idea to document it so that the developers in future don't make the same mistake and avoid that bad solution at the first place? Like patterns, Anti-patterns also have components. Below is the list of the components of an Anti-pattern solution:

  • Name
  • Problem
  • Context
  • Forces
  • Supposed Solution
  • Refactored Solution
  • Examples

Why shouldn't we ignore Anti-patterns?

We shouldn't ignore Anti-patterns because:

  • To avoid bad solutions: An Anti-pattern documentation points out the BAD solution so that we can avoid them
  • They suggest good solutions: The Refactored Solution section of an Anti-patterns document actually leads to a good solution
  • It alerts the user showing why a bad solution is attractive: In Forces section, an Anti-pattern tells us why a bad solution is attractive
  • Shows where the Anti-pattern can be found: An Anti-pattern solution gives the example of fields where that particular Anti-pattern can be found so that the user can be careful about those fields

Therefore, we can conclude that we shouldn't ignore Anti-patterns; rather we should study them so that we don't fall into the same trap that others suffered.

Reference:
[1] Freeman, E., et al. 2004. Head First Design Patterns. p. 606

2 comments:

Bash said...

"When a good pattern is applied by a wrong person, it becomes an Anti-pattern" Thats an interesting quote. Even good developers come up with a wrong solution. We can not make a solution right the first time. Anti-pattern makes sense only in a certain context. For example, abstract factory involves inheritance and polymorphism. Can you write an abstract factory in C or Pascal?

M Nuruzzaman said...

Well said Bash. It is true that sometimes experts can come up with improper solutions and without the proper directions of how to use a particular pattern, it can cause more problems than solving one. That's why we shouldn't ignore Anti-patterns. We should call them "Traps" maybe and include them with patterns so that the users knows what a bad pattern looks like and be careful about using that. Thanks for sharing you thoughts.