3 Feb

What is the big deal about design patterns?

Posted by Sarath Revuri in Design Patterns | Tags : |

What is the big deal about design patterns? Is it the “holy grail” of object-oriented programming? Or, is it just some fad used to over-complicate a project’s design? If you’ve ever known me for any amount of time [as a programmer], you should know that I am an avid champion for both object-oriented design, as well as design patterns. With that said, this article will be biased toward the use of design patterns; the intent of this article will be to explain why I prefer using design patterns, as well as what I feel its benefits are for you as programmer.

What are design patterns? More specifically, why should you care?

As with any technology, there may be one or more specific meanings that are commonly used to describe the technology. I feel that this is especially true when it comes to computer science, and the application of design patterns. To quote Wikipedia, “A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise.” What does this definition really mean? To me, it means that a design pattern is an abstract way to describe a problem through logic and structure in your code; i.e., you write your code in such a way that it reflects the idea behind what the design pattern is supposed to achieve.

To put it more simply, a design pattern by itself is not a solution to a problem; the only solution to a problem is the code itself. A design pattern is nothing more than an idea of how the programmer decides to look at a problem, which helps them determine the code that they will write. This is just as true as saying that it is good practice to encapsulate a piece of code through inheritance or abstraction. It is just another design principle of “good object-oriented design”.

Design Patterns just over-complicate code!

Actually, no they do not. If a correctly-implemented design pattern looks complicated, it is more likely because the person reading the code does not understand the design pattern, not because the design pattern is complicated. Every time that I think about this argument, I can’t help but to remember a time back when I was first starting out and I came across some code that used the Singleton design pattern. At this time of my career I had never heard of design patterns, and I didn’t even know what object-oriented was (remember, we are not born programmers; we are learned programmers). I remember cursing the original programmers for using such a “stupid and over-complicated” technology; in reality, I just never understand its purpose, and what benefits it gave to me.

Since then I’ve done everything that I can to learn about object-oriented design, and design patterns, and when I look back on that memory I can’t help but to laugh at myself because of my knee-jerk response to something that I had no working knowledge about. This type of response is a similar response that I’ve gotten these past few months at my current employer. It’s frustrating as a developer to hear this type of response, especially from colleagues who are otherwise very intelligent and responsible developers. I digress…

The use of design patterns are not meant to simplify (read: reduce) your code. They are meant to simplify the complexity of your ideas, and the expression of those ideas. For example, which is easier for you to read and repeat:

We need to collect a large amount of data from the Acme sources, parse those sources into a format that is understood by our system(s), and then run several different sub-applications to display results, store results, generate reports based on those results, as well as notify our users that we have updated our results. Additionally, we need to be able to add/modify this process at any time, without having to modify the code very much.

or…

We need to use the Observer pattern to distribute the results that we model from the Acme sources. Some observers that we will use will display, store, generate reports, and notify our users. Other observers may be introduced at any time.

As a developer, I can say that I prefer the second version of these requirements. It tells me everything that I need to know, without having to get too deep into the implementation details. And, if we needed to explain this system to a non-developer, we can simply omit using the phrase “Observer pattern” and “observer” to make it more generic and understandable.

While I understand that there is a semantic difference between complex code, and complex logic, I find that complex logic is less complex once that logic is understood. What I mean by that is if you, as a developer, understand another developer’s rationale, you are less likely to think of their idea(s) as complicated. With that said, if more developers were to understand object-oriented design, and design patterns, the argument that design patterns over-complicate code would dwindle. So, as a developer, you have to ask yourself: do I care enough about programming to continue to learn new techniques, or am I comfortable enough with my current level of knowledge to not bother putting in the effort?

If you aren’t willing to understand something, then what right do you have to complain about it? Certainly, how do you expect to argue for or against something if you are not willing to understand it?

References and Reading Materials

Original Source:  http://dohpaz42.wordpress.com/2011/01/27/design-patterns/

Respond to this post