Table of Contents
What Is The Best Way To Learn Design Patterns?
Design patterns are high-level answers to recurrent issues encountered by software developers. It is not code. It provides a walkthrough on how to approach these issues and devise a solution. You can learn graphic design online through Blue Sky Graphics online graphic design course.
Using these patterns is considered excellent practise since the solution’s design is well-tested, resulting in better readability of the final code. Design patterns are often developed and utilised by OOP languages such as Java, which will be used in the majority of the examples that follow.
Design pattern classifications
There are presently about 26 Patterns identified. There are three kinds of these 26:
1. Creational: These patterns are intended for instantiation of classes. They may be class-creation or object-creation patterns.
2. Structural: These designs are made with the structure and composition of a class in mind. The primary aim of the majority of these patterns is to enhance the functionality of the class(es) concerned while retaining the majority of its composition.
3. Behavioural: These patterns are created based on how one class interacts with another.
We will go through one fundamental design pattern for each categorised category in this article.
Type 1: Creational – The Singleton Design Pattern
The Singleton Design Pattern is a Creational pattern with the goal of creating just one instance of a class and providing only one global access point to that object. Calendar is a typical example of such a class in Java that cannot be instantiated. It also makes use of its own getInstance() function to get the object to be utilised.
A singleton design pattern class will contain the following elements:
Diagram of a Singleton Type
A private static variable that stores the class’s sole instance.
Because it is a private function Object() { [native code] }, it cannot be created elsewhere.
A public static method that returns the class’s solitary instance.
The singleton concept may be implemented in a variety of ways. I will be going through the implementations of today’s;
1. Eager Instability
2. Lazy Instantiation
3. Instantiation that is thread-safe
This kind of instantiation occurs during class loading because variable instance instantiation occurs outside of any method. If the client programme does not utilise this class at all, this is a major disadvantage. If this class is not utilised, the Lazy Instantiation will be used as a fallback.
Days of Dozing Off
There is not much of a difference between this implementation and the one mentioned before. The major distinction is that the static variable is declared null at the start and is only created inside the getInstance() function if – and only if – the instance variable is null at the time of the check.
This solves one issue, but it leaves another unsolved. What if two clients visit the Singleton class at the same millisecond? They will, however, verify whether the instance is null at the same time, and if it is, they will construct two instances of the class for each request made by the two clients. Thread Safe instantiation will be used to address this issue.
The most important thing to remember is safety.
The term synchronised is used on methods or objects in Java to provide thread safety, ensuring that only one thread accesses a specific resource at a time. The class instantiation is placed inside a synchronised block so that only one client may use the function at a time.
The synchronised approach has a significant overhead, which decreases overall performance.
For example, if the instance variable has already been instantiated, the synchronised function is executed each time a client calls the getInstance() method, and performance suffers as a result. This is simply done to determine if the value of the instance variables is null. If it discovers that it is, it abandons the technique.
Double locking is employed to minimise this cost. The check is also performed before the synchronised method, and only if the value is null is the synchronised method executed.
Type 2: Structural – The Decorator Design Pattern
You must now have those two add-ons, both on the menu and, regrettably, on the billing system. Initially, your IT guy will create a subclass for both coffees, one with sugar and the other with milk. Then, since consumers are always right, the terrible words are uttered:
Once again, the world is against you. A rival comes up across the street, offering not just four kinds of coffee, but also more than ten add-ons!
You purchase all of that and more in order to sell better coffee yourself, only to realise that you neglected to update that dreadful billing system. You may not be able to create an unlimited number of subclasses for each and all combinations of all the add-ons, including the new coffee blends. Not to mention the ultimate system’s size.?
It is past time to invest in a decent billing system. You discover fresh IT employees who know what they are doing and they tell you;
What in the world is that?
The decorator design pattern belongs to the structural category, which is concerned with the actual structure of a class, whether through inheritance, composition, or both. The aim of this design is to be able to change an object’s functionality during runtime. This is one of many other design patterns that combines abstract classes and interfaces with composition to achieve its goal.
Let us use Math to put this all into perspective: we remove one from ten since you can not mix one add-on with another of the same kind; sugar with sugar sounds silly. And that is just for one coffee mix. When you multiply 81 by 4, you get a staggering 324 different subclasses! What about all that code…
Class diagram based on a coffee shop scenario
If we draw out our situation using the class diagram above, we get four classes for each of the four coffee blends, ten for each add-on, one for the abstract component, and one more for the abstract decorator.
As seen above, the AddOn abstract class derives its methods from the beverage abstract class, just as the concrete coffee blends are subclasses of it. The add-ons, which are its subclasses, inherit any additional methods that are added to the parent object as required.
