The Perfect Storm of Design Patterns

I was assigned the first task of my life. Writing a small library to process data stored in a file. Some of the code was already written by a senior programmer in another programming language. My task was to write the similar code using C#.

I was new. I learned object oriented programming and object oriented analysis and design in college. I also practiced some design patterns for job interviews and I knew this adage:

Knowing how to use hammer does not make you an architect

Knowing C# or Java or any OOP is like how to use the hammer. To be a good architect you need to know the object oriented design and patterns.

So, I started reading about the all the OO design patterns and principles before writing a single line of code. My boss kept asking about the task and I said that I wanted to become a good architect.

What was I doing? I was reading about 10+ design patterns. During that time whatever the literature I found was super boring and complex. I thought it is important that is why it is complex.

There were no practical examples in the material that I found. Only simplest, boring and unrealistic examples of the design patterns (e.g animal and duck examples)

Then one day my boss interrupted me. He asked why is it taking so much time in writing this software. He asked me to show him any code that I have written.

Guess what!

I have not written a single line of code in 4 weeks!

object oriented design

Instead of showing him any code, I open up a document where I have gathered all the design patterns and principles and I showed that to him. A full report on how I will use all software design patterns- a perfect storm of patterns.

I told him this:”I want to write a code which is easy to extend, modular, testable, reliable…. Blah blah”

I want to show off that I knew dozens of design patterns and then my boss said: come on man. Just start writing some code.

I did this again and again and I know that I am not alone. Many web developers who are impressed by MVC design patterns tried to learn every other design patterns and use them in their next project.

Now, I understand why we have this urge to know all patterns. Now I know how to strategically learn and apply design patterns. I will share my experience with you in this post. You can apply this knowledge in your projects.

Once you know how to strategically apply patterns you can beat your peers by showing off your vocabulary of patterns. And after seeing your code your boss would say: ”You truly understand object-oriented design principles and patterns”.

Again, learning patterns will also be personally good for you. For example, a couple of months in a project — you look back at your code and you start smiling because your code is self-explanatory.

First discussed some problems that cause me to apply all design patterns in that small project. I believe you have faced these problems too.

Problems Between You and a Good OO Design

Most of the literature available for object oriented design and patterns is so complex and boring that it will hurt your eyes.

Another problem, we want to learn all patterns that are available in the literature in one go. Learning is not bad. But thinking of applying all patterns in the next project is absurd.

This was the same case with me. I believed until I don’t apply all principles, my code will not be quality code.

Another problem, opposite to the above, knowing a small number of patterns.

knowing only a small number of patterns creates a tendency to apply them frequently and eventually in wrong places. For example, initially, I know singleton pattern.It was easy to learn. I applied it frequently even when it is not needed.

If all you have is a hammer, everything looks like a nail

So, these are the problems that caused me to use design patterns in the wrong manner.

Following are three solutions that will be helpful.

1) Develop Competency

We have to understand the what is competency. How competency is different than knowledge?

Knowledge is like reading and understanding properly.

You can have knowledge of dozens of techniques. It means that you have learned these techniques and knows every input and output.

Competency is when you are facing a problem you know which technique to apply in order to solve that problem. Therefore, knowledge is having a collection of techniques and competency is which technique to use from that collection when you are facing a real-world problem.

How can you develop competency for applying design patterns?

It’s simple. Start small.

Learned 2 or 3 patterns and apply them and measure output. Apply them in few projects before moving to next set of patterns. In this way, you will have proper understanding of the patterns

Another way to develop competency is to study the real-life examples. If you learned from the animal and dog examples you will definitely fail.

You can also develop competency by developing your own collection of patterns.

What is a pattern?

It is a solution to a recurring problem. If you have been programming for at least 1 year you will know that there are recurring problems in your domain. For these problems, you can develop your own set of patterns.

A few months later you can learn the patterns in the literature and gain competence very quickly. More on that here

2) Don’t Wait for the Perfect Design

There are situations when you as a programmer unable to decide which design decisions to make. You haved discussed with your peers, with your boss but you are still indecisive.

There is one key to unstuck- that is just go for it. Taking action will make you forward.

Later on, you can refactor it to make it better. For now, don’t wait for the perfect design. The short rule that I used is 2 hours of design work for 1 week of coding.

3) Don’t Anticipate Everything

There is an another aspect of perfect design. One of the key features of the object-oriented design is to design for any future changes or upgrades.

Due to this, you want to give indirection to every module of your software(Many design patterns are based on indirection)

You want to make it easy to change. You want to make it easy for a software to integrate with any other software developed in the future. In short, you want to make your code future-proof.

Making everything future proof will take a huge chunk of your efforts. And when after 2 years you realize that predictions that you made earlier did not happen. You will feel bad about the wasted effort.

Additionally, your software will be complex and you will have to handle a number of classes when designing with indirection.

For example, once I developed a software for handling 2 types of input files. I thought what if there is another type of input file. So I make my software future proof by applying indirection patterns. This creates additional 5 days of work.

One year later, I realized that there will be no third type of file. Hence useless anticipation made the software complicated and caused unnecessary work.

Hence while making your software future proof make sure there will be an actual requirement or there is a real possibility. And don’t just act on your own whim to make the code future proof.

Over to you

So, developing competency will make you perfect in applying design patterns. Similarly getting over the urge to wait for the perfect design and just go with the design will make life easier for you.

Finally, unnecessary anticipation will force you to use a whole lot of design patterns and complicate your design.

What problems do you face when applying design patterns. Tell them in the comments below.