Design Patterns Reinstated July 10, 2007
Posted by WarpedJavaGuy in java, programming.trackback
A wise programmer will never discard of a good design pattern.
If the previous generation of programmers gave us design patterns and the current generation gave us anti-patterns, what will the next generation give us?
The programmers before us did a lot of programming and solved many common and recurring software problems. They identified several reusable design solutions and introduced them to us as design patterns. They did this at a time when object oriented programming was in it’s prime and when Java was the next big thing.
The Java community embraced and adopted design patterns as a best practice for robust software design and development. Patterns quickly gained popularity and were a huge phenomenon. But as their adoption grew and as Java technology progressed, classic patterned solutions suddenly started to fail. Although unwelcomed, this was to be expected. After all, design patterns were new, Java was new, and developers were new to both of those.
Many patterns were misinterpreted, wrongly implemented, and misused. Some of them were adhered to correctly but failed on the technology or platform that they were being applied to. This lead to the introduction of anti-patterns; failed solutions that are the exact opposite of what design patterns were meant to be. Anti-patterns had an unfortunate tarnishing effect on design patterns and have resulted in modern programmers becoming increasingly skeptical and critical of patterns in general. This is both good and bad news! The bad news is that design patterns have been repeatedly bashed and misconstrued. The good news is that we now have patterns and anti-patterns and can clearly distinguish between the two. There is no good reason to bash patterns that are anti-patterns and there is no good reason to bash patterns that are not anti-patterns.
We are now in a good position to embrace and re-adopt design patterns and establish better design practices for the current and future generations. If we fail to do this, we will be responsible for the demise of design patterns and the damage that their absence would cause to the programming community. We could also be responsible for a rebellious movement of next generation programmers who take pleasure in singing the following song ( to the tune of Pink Floyd – Another Brick In The Wall ):
We don’t need no design patterns.
We don’t need no code control.
No more patterns, they are old skool.
Amigo leave our code alone.
Hey! Amigo! Leave our code alone!
All in all they are just anti-patterns that’s all.
All in all they’re all just anti-patterns that’s all.
It is also worthy to note that the current generation programmer may already be singing this song ( to the tune of Prince – 1999 ):
They say in 2000 design patterns were so very cool
For their time!
So tonight I’m gonna program like it’s 1999!
1999!
Design Patterns have always been more of a “nice to have” than a necessity. You can get by without them, but chances are your code will not be as elegant or manageable as it would by employing Design Patterns. So when developers attempt to use Patterns, either incorrectly or inappropriately, again they end up with inelegant and/or unmanageable code, but it nevertheless still works.
So even if you don’t apply Patterns properly, you may still have the perception that you have, so you put it on your resume and further propagate the myth that you know what you are doing. The same can be said for Object-oriented Programming – whilst we may be using languages designed for OOP, much of the code implemented in these languages does not adhere to OO principles.
Software developers are a lot like self-taught musicians. You pick up a lot of bad habits along the way that can be very difficult to unlearn.
With modern languages making more and more concessions for lazy programmers (dynamically-typed languages?), I don’t see a bright future for Design Patterns, or elegant code in general for that matter. I think we can only hope for a revival of Design Patterns and good coding style as the result of a backlash against the ugly code that is being produced today. Then again, maybe not.
I totally agree with your comment that bad habits are difficult to unlearn. And this indeed highlights the crux of the problem.
There will always be ugly code out there, with or without design patterns. We really need to learn how to better apply patterns at the design level. We have failed to do this in the past because programmers got too excited with the whole code reusability concept. They took on the roles of both designers and developers. They even packaged their implementations of patterns as if they were reusable framework components.
I have had several debates with developers in the past over pattern reuse Vs code reuse. Patterns are reusable design solutions, and not reusable object binaries. Yes, you can apply one design pattern solution to many designs. But no, you cannot write one design pattern implementation and expect to reuse the code everywhere.
We need to unlearn these bad practices. The future for design patterns should be all about better designs that promote better development.