The idea of best practices was the key. It seems awesome that some experts from the history(even the ancient history) have outlined tested solutions to common and recurring problems.

Our undergrad teachers tried to teach us but they were not helpful. We were bogged down to definitions only. This is because I knew that there were huge differences in understanding the details of design patterns among my teachers. Nobody had the complete understanding of design patterns.

But I was motivated because I have to become an architect someday. You know, I don’t want to be a mere programmer or developer but an architect. Someone ahead of the curve. What a Dream:)

Anyway, discourage from teachers I turned my attention to books. There are great books available on the subject of design patterns. But the majority of these books consist of complex writings and examples. Most of the examples are distant from real life and the real world. Understanding from those books is a difficult job and applying the concepts from those books is even more difficult.

On the other hand, some stuff is very basic and hardly progresses into the real world. For example, the ‘duck’ and ‘animal’ examples of some books are naive. But it does not bother me if someone starts with naive examples.

But if someone is stuck on those naive examples throughout the book– this does make me hate the book. With naive examples, it is easier to understand the concept. You will understand every example, every benefit of a design pattern and design principle when you are reading those naive examples. But when you try to apply those concepts in your own projects- you will be stuck because the real world is not naive.

Similarly, if a book starts with complex examples then it becomes difficult to understand the basic concepts and ultimately impossible to apply them in your own projects.

Therefore it is so important that we should start with naive examples and then progresses into real-life and real-world examples. I can help you with that but our goal is not to study the examples of object-oriented design principles/design patterns and feel good about ourselves.

Our goal is to apply object-oriented design knowledge into our projects. Get real benefits of OO design. From my personal experience I can tell you that it all boils down to one thing and that is:

Decisions!

It is common to think that certain things are complex or there are too many factors and I cannot take decisions. For example, there are too many classes and I don’t know where to put what responsibilities. Or if I only know that particular pattern completely then I will be sure.

The truth is that we are fearful. What if something goes wrong? What if that particular decision does not do the work? What if some other developer makes fun of me for writing bad and smelly code?

But wait. Are you alone in this? I believe not. Even the toughest and sophisticated architects were once beginners and they made similar mistakes.

Highly paid and sophisticated architects in the organization like Microsoft have come up with bad decisions (e.g Microsoft XNA, Silverlight) and then rollback their efforts.

I have attended Microsoft PDC (now called BUILD) and have seen technologies introduced in those conferences which are dead now.

So, architecture is all about decisions. These decisions could be good or bad. It’s not science its heuristic. There is no science or formula that can prove or disprove your decision.

The only thing that you can do is to take a decision with the knowledge that you have at that period (or moment) of time and you should not be guilty about it.

What does it mean? Suppose you took a decision and later in the project you find out that the direction you took a couple of months ago is not working. What will you do? Think about it.

Here are some options:

1. Feel guilty about it and do nothing
2. Do the necessary changes and feel guilty about it
3. Do the necessary changes and feel proud about yourselves

I don’t want you to take the first option. Nobody will tell you to do that initially.

As a beginner, most of us take the second step. Feeling guilty will resist us to do anything productive the next time. Feeling guilty can and will hinder our growth. Eventually, you will find yourselves paralyzed. Feeling guilt and doing nothing, only searching for the next best tip to apply design pattern, is a disastrous approach.

What you can do is that think about this in this way that you have taken the decision under certain conditions and you have done your best. Just reflect on those conditions and the things that forces you to took those decisions and then took a note of them.
Reflect on your environment because you took decisions according to your environment.

Your existing skills are also the part of your environment

Designers’ decisions are mostly influenced by environment. Similarly, you have to take decisions according to your own environment and it is nonsense to judge your decisions because nobody can understand the circumstances in which you took certain decisions.

Maybe it is your boss who is asking you to do your job in a certain way. Maybe people working on your team look at your design and do not confirm. Maybe you don’t have time. Whatever, you know your environment and its constraints.

Your existing skills and experience is also the part of your environment. You are at a certain level of the learning curve. Even the most experienced developers don’t know the nuances of certain design patterns/principles. So you have a limited level of knowledge — no matter how experienced you are.

But you have to take a decision. Take the decision with whatever the knowledge you have at that moment. Maybe later you realize that your decision was wrong because you didn’t have the skills or vision but don’t judge yourselves and don’t lament for so long.

What to do then?

You can always work on your skills and improve yourselves. Once you are at a certain level of expertise, you can look back your previous work and you can laugh about it but always remember that was the best thing that you can do at that moment.

Consider the oldest version of Java, Dot Net or Windows or even Mac. Were they the best? No. Will the current team look at them and laugh about it… Probably YES.

So don’t worry if you think you are a beginner and you don’t have the perfect idea of how to take the right decision or how to apply particular design pattern properly the very first time.

What you can do is apply your skills and just wait. Let it grow. Later, when you come back to it then you will know whether your decision was right or not.

You will come back to it, I know it for sure. You will come back to it for change or update. There is always some change or update that is remaining.

You may come back because another developer is working on the same codebase and wants to know about your decisions. You can show him your code and while you are showing him you have the chance to reflect on your decisions.

When you open your code and review your decisions. You will know that the decisions you took and the benefits you thought are working or not. If not you will know why and what you need to change.
There is another way to this and that is:

Reflect Proactively

You can schedule yourselves to do code reviews in 3, 4 ..  and 6 months or so and refactor your code. Look for the bad smells in the code. That is the code you have written without thinking about it.

As it is the outlined in a great programming book, Programming Pearls, that programming is not just one act. Programming is about analyzing the problem in all aspects.

This includes planning before writing the code. Then writing the code to solve the problem and then review it afterward to learn what worked and what did not.
So, finally, the question time what are the problems that you faced while applying design patterns?

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!

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.