A few months ago, I needed to see a skin doctor. Selecting the right doctor was important because treatment will take around six months and requires financial and time commitments.
Therefore, I asked friends and relatives. I asked those who were treated successfully and even those who were not.
Time was ticking because the problem could get worse if I did not take the action.
Today, I am thinking that did I make the right decision? The total number of people I talked to was 15. Is this a good sample size to select a doctor who is going to treat me physically?
Another method would be to get 5000 people who were treated by each doctor and draw a graph and do statistical analysis and select one in the top 1%.
That would be insane 🙂
Anyway, I selected the doctor based on simple research and got treated successfully.
Software engineers like me are skeptical. I need a statistically powerful study to support any argument or idea or design principles.
Because developers who know about object-oriented design are mostly show off. They were only dropping big terms to impress junior developers.
But there is a serious lack of scientific studies in OOD and let’s explore why. In any research, the sample size must be statistically powerful. The larger the sample size the better the quality of the research. But studying larger samples requires more resources.
A large study requires management for administration. Experts for evaluation. Participants in the study volunteer or paid. Time because a large study can take months and years. Constraints to enforce e.g. testing for a variable and keeping other parameters constant.
Imagine asking what would be the benefits of applying polymorphism in 500 different software development projects while keeping everything else constant. But keeping things constant is difficult in software projects.
I searched for such studies where hundreds of software projects participated and people measured the effectiveness of ‘X’ design principles or patterns. I have not found one yet.
This was very heartbroken for me:). I only trust something when it is supported by a significant scientific study or a mathematically proven formula. Using formulas is another love for analytical persons.
I love formulas because I love Galileo. He once deduced that all objects either heavy like a hammer or not so heavy like a bird’s feather will fall at the same speed. Galileo said it hundreds of years ago and NASA has tested his mathematical capabilities in a lunar mission. See the details on the moon:
Object-oriented design Formulas
In the beginning, when I was learning about design patterns I thought of them as mathematical formulas. I believed if I use ‘X’ design pattern then I will get ‘Y’ benefits.
I even went one step further. If applying one design pattern as a formula is helpful then why not apply all the design patterns and get the aggregated result.
Guess what? It only works when you are applying design patterns in class or demo projects. In real-world projects, it does not work like that.
So what is the solution?
The most effective method is to select one design principle and apply it and test it for yourself. You will know if it is working or not.
Easy? If it is easy then what is the purpose of design books? Books do not promise you the competency.
There are two types of books. One is catalog books e.g. ‘Design Patterns: Elements of Reusable OO Software by four amigos’. They are boring, dry, and complex.
The second types of books contain personal experiences and basic examples like animal and duck e.g. ‘Head First Design Patterns’. They are basic and fluffy.
My article on object-oriented design patterns tries to be both i.e. good reference and real-world examples.
No design books claim to be the perfect book and everything authors find helpful may or may not beneficial to you.
“All you can do is take the vocabulary, take the inspiration, apply yourself, customize the design patterns to your needs and most importantly observe the benefits.”
Consider the doctor I chose for treatment. What if I don’t see the benefits after 2 or 3 months? What would I do? I would change. If something is not working or you are not getting the desired benefits you can drop it. Or try again in another project.
Do this repeatedly and you will know if the design pattern or principle is going to be effective or not. That will be the moment when you become someone who used to know about patterns and now you are competent in design patterns.
Ultimately, you will see the following benefits of design patterns:
a) Your strong code structure helps you to go home early because it does not break with the new changes. OOD skills help you convert a fragile codebase into a stronger one.
b) Imagine there is a new framework in the market and companies are hiring at higher salaries for developers adept in that framework. It will only take days for you to learn that framework because it is an implementation of one of the design patterns.
c) You will feel good when you see a junior developer using your framework and enjoying all the benefits that you have envisioned years before.
If you want to learn more about real-world examples of object-oriented design then check this out.