Let’s talk business. Design patterns. When I was first introduced to design patterns during my graduate classes I immediately become motivated to learn design patterns.
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:
- Feel guilty about it and do nothing
- Do the necessary changes and feel guilty about it
- 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?