Hi everyone, I hope everyone is doing good and fighting against the Covid-19.
Today, we are going to start an old topic on which we already have tons of material, but still, I feel a lot of developers are facing a problem, and I am also one of them. This post will be theoretical, so if you are expecting something practical about Design Patterns, then this post is not for you. Most probably, the next part will be for you. So it’s time to start :).
Motivation:
I am not going to say, everyone faces the issues with this topic, but in my circle, I find out a lot of developers are facing issues, including me. So first, we can discuss what type of problems mostly we observed.
- Sometimes the developer watched a video lecture on something, and he finds out a person used some Design Pattern. Now he starts copying that same technique without knowing his use case is not suitable for that particular Design Pattern.
- Sometimes I find out, the developer is motivated to learn Design Patterns, and he did Google about Design Patterns. Now he finds out a Builder Pattern as a Creational Pattern. So he starts copying the same structure of code from that resource into his system and not able to see his use case not require any Creational Pattern.
- Sometimes the developer starts reading a book on Desing Pattern. Now, he completed two Design Patterns, so the next day, he starts trying to achieve that pattern in his current task, which is not suitable for his task.
- Sometimes I find out a developer did a code review, and he finds out some Design Pattern used by his colleague. Now, he did google and find out a different approach to implement the same Design Pattern. So he decided to give this new approach for implementation without knowing both are doing the same thing.
- Sometimes I find out some learning resources using the same scenario for teaching all types of Design Patterns. This is not bad, but for the new learner, it’s a big problem because now he will try to implement any Design Pattern into his use case. For example, I saw Employee, Order, and Shape type of scenarios used to teach all Design Patterns.
Confess: All above observe scenarios I find out in my self 🙂
Second, the big issue I observe is Creation Patterns only. Mostly books or blogs when they start teaching Design Patterns, they divide into three to four categories. Creational, Behavioural, and Structural Design Patterns, and mostly they start from Creational Design Patterns.
In a way, some Creational Design Patterns are easy to grab like Singleton, Factory, so most developers got a lot of motivation by using these, and that is enough for them to motivate.
Confess: Above observation, I find out in my self 🙂
WHY:
This is important to know why some developers face this issue. So one day, I asked myself this question. I have a very long discussion with myself on this, and it took too long to find out the problem, but after spending a lot of weeks, I find out a problem which I am going to share with you, this is my opinion, and you are allowed to disagree with this.
As my brain is always thinking about this issue, one day, I find out the problem. So what I find out is fantastic, and I will share with you some of the things maybe you can relate that with yourself.
One day, I am reading the book “Thinking fast and slow,” and as per this book, we have two systems in perspective of our brain working. One is Conscious, and the other one is Unconscious, and this information solves my problem not only related to the Design Pattern.
So when I started my university, they teach us Introduction to Programming. In which I learned if, else, for loop, while loop and functions. I used this knowledge around three to four years to resolve all my coding assignments. I am doing a lot of practice of these concepts. As a result, this information now part of my unconscious brain.
To make this easy for everyone, that is the same when you start learning a bike or car driving. At the start, you are focus on every step. As you do more practice, your brain moves this information from conscious to unconscious, and after some months or years, you can drive a car while listening musing or attending a call ( Don’t attend a call when driving ).
This is the first issue I find out in my professional career. Every time I have a tight deadline, my unconscious always throw me to use
If ()
else If()
else If()
else
and complete a task, and that never throw me the idea of Polymorphism because my brain wants to help me, and I already train my unconscious with these basic concepts and not with the Design Pattern.
Second, I find out we learned Object-Oriented Programming, and I used that also around 2-3 years in my assignments with the help of if, else for and while loops. But the bad part is, we spend a lot of time on inheritance and we spend only one or two lectures on Composition, which is an important concept to be good with Design Patterns.
Now, the problem is not the Design Patterns; instead, my brain is trained in the wrong way. Mostly in an Agile environment, we have tight deadlines in which we need to complete our tasks, so in these types of situations, we are more dependent on our unconscious, then the conscious mind.
Sorry, I am going out of the topic but only to prove my argument. You can ask a question to some developer who has a lot of experience with development, but he is not able to pass the online test.
Why you hate online tests? He/She will respond to you with the answer, “I am writing code from 8-10 years. I manage big teams and launch many great products. I think these tests are far away from reality”.
When I dig deep into this issue, I have the same answer. Mostly, we are not good with recursion because we don’t spend a lot of time on recursive algorithms, and due to that, most people are not able to pass these online tests because these mostly depend on Dynamic Programming or Recursive solutions. Still, our brain always tries to resolve these questions by using if, else, for loop and while loops.
Solution:
Its time to discuss how we can fix this issue and make ourselves better with Design Patterns.
In this series, our main focuses are not a Design Pattern. Instead, we will learn about the different scenarios or use cases, and later we will map our use cases with Design Pattern definitions. That will be a straightforward technique. For example, I can give you a direct example. I have an object which has six fields.
class OurObject {
private String field1;
private Double field2;
private String field3;
private String field4;
private Integer field5;
private Long field6;
public OurObject(String field1, Double field2, String field3, String field4, Integer field5, Long field6) {
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
this.field4 = field4;
this.field5 = field5;
this.field6 = field6;
}
}
Now, in this use case, we find out field1, field2, and field3 are mandatory, remaining fields are optional.
We will go into our Design Pattern definitions cheat sheet (Which I will share with you in the next post). We will try to map this use case to our definitions and find out that is the definition of the Builder Pattern.
Builder Pattern: Optional Vs. Mandatory
Simple, now I don’t care what is the name of your object we know the use case is mapping to our Builder Design Pattern definition, so implement this Design Pattern.
Note: Sometimes, we will face some scenarios where we need to map against multiple Design Pattern definitions. Still, we can achieve a proper solution by using this technique we will see in the next posts.
class OurObject{
//Mandatory
private String field1;
private Double field2;
private String field3;
// Optional
private String field4;
private Integer field5;
private Long field6;
public String getField1() {
return field1;
}
public Double getField2() {
return field2;
}
public String getField3() {
return field3;
}
public String getField4() {
return field4;
}
public Integer getField5() {
return field5;
}
public Long getField6() {
return field6;
}
private OurObject(){ }
public static class Builder{
//Mandatory
private String field1;
private Double field2;
private String field3;
// Optional
private String field4;
private Integer field5;
private Long field6;
public Builder(String field1, Double field2, String field3) {
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
}
public Builder setField4(String s){
this.field4 = s;
return this;
}
public Builder setField5(Integer i){
this.field5 = i;
return this;
}
public Builder setField6(Long l){
this.field6 = l;
return this;
}
public OurObject build(){
OurObject ourObject = new OurObject();
ourObject.field1 = this.field1;
ourObject.field2 = this.field2;
ourObject.field3 = this.field3;
ourObject.field4 = this.field4;
ourObject.field5 = this.field5;
ourObject.field6 = this.field6;
return ourObject;
}
}
}
My implementation is not the only implementation, we can implement this by using different approaches. In my opinion, implementations are not a difficult task instead difficult task is to find out a suitable Design Pattern.
Second, in our posts, hopefully, you are not able to see any terminology like Client, Concrete, Abstract, Base, Component … Instead, you will map the use case against the cheat sheet definition of the Design Pattern. Once this step is complete, we will implement, and later you can see who is a Client, Concrete, Abstract…
Conclusion:
In my opinion, there is no need to blame anyone. Instead, Design Patterns are not arrogant. Only we need to review how we train our brains, and if we feel we need to fix our unconscious, then we need to spend a lot of time to do the practice again. Still, this time our goal is not to complete the task; instead, our goal will be to complete our work with better code by using best practices.
This is not true for everyone. A lot of times, developers got tremendous mentors at the start of there carrier, so they never face these issues sometimes; your universities make extra efforts, so you never face these issues, or sometimes they want. Still, due to a lot of circumstances, they are not able to help you. Even okay, but now we can improve once we know the problem. 🙂
More Posts on Design Patterns https://www.uwanttolearn.com/design-patterns/
by 