Please first read my blog regarding embedded fields in Golang here.
What is Design Pattern?
By Wiki: In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Command pattern:
The Command Pattern allows you to decouple the requester of action from the object that acts. Let’s say your team building a universal remote which can start any car that the user owns.
Now your remote doesn’t need to know that whether you are operating Tesla or BMW. When the user press starts on the remote, it will start the car paired with the remote.
Observer pattern
Let’s say you want to build a system where there is an N number of observers, who want an update, whenever there is a change in the state of the subject. And observers can register and unregister from this service effortlessly.
To do that job, there is a famous design pattern, in which, the subject can have a HAS-A relationship with the list of observers, and have functions like register and notifyObservers. Now, every observer will inherit the Observer interface and then can register or unregister itself by calling the function of the subject class. And, to notify all the observers, the subject just have to call notifyObserver which will iterate through all the observer’s list, and call notifies function, which they have inherited from the observer interface.
Decorator pattern
Let say, you have a coffee shop(Component), and you wanted to have a function in your coffee class that will give you the prices(Operation) of the coffee. You sell different types of coffee with various toppings. Sometimes a combination of many topping. It will be a headache for you if you create classes for each combination.
The Decorator pattern is here for you!! Assume you need to add a cream topping to the cappuccino. Now you know that the resultant thing will be a coffee again right. First, we will create the cappuccino class (Concrete Component) which will inherit the coffee class(component). Now, we will add the topping(ConreteDecoratorB) by making an object of it and pass the cappuccino class object in the constructor. As decorator has a HAS-A relationship with the Component. Now when you call the price(operation) function, it will first call the operation function of base class plus topping price(addedBehavior).
Factory pattern
Now, Your coffee business is running great as you were using an excellent decorator pattern and now you decide to open a pizza shop. Here the requirement is a bit different, as here you need to bake a different type of pizza, and then you need to perform various operations on it like cutting, packing, and serve.
Indeed, you don’t want to do all this in the client function which needs an instance of the pizza class. It should depend on abstractions.
Object Pool Design Pattern:
Almost every project uses a DataBase right! We make so many calls, and we keep on updating the DB. But we want to control how many concurrent calls are happening. As well as we don’t want to create a connection for every new query.
The Adapter pattern:
Let’s say your PM gives you a weird task. In your project, you have a bird class(target) and a turkey class(Adaptee). Now, we all know how turkey flies. Your PM is asking to perform all the tasks on the turkey class that you were performing in bird class.
Here comes the need for an adapter, it will inherit the target interface. So this adapter class(Flying turkey) will be a bird as it is inheriting the target interface. But still, it will be a turkey. Now, when someone calls the fly function(Request) of this bird object, we will call the flap(Specificrequest) function five times of turkey class to give an effect of flying 😜
Some other design pattern you should read: Strategy Design Pattern, Singleton Design Patterns
