Many software engineers could work for many years without knowing a single pattern. It can also happen that we are applying a pattern without even knowing it.

Software Design Patterns

Design Patterns represent some of the most acceptable practices experienced object-oriented software engineers utilize. In object-oriented systems, a Design Pattern methodically names, motivates, and describes a general design that addresses a recurring design challenge. It explains the problem, the solution or approach, when to use it, and the ramifications. It also includes tips and examples for implementation (although a design pattern is not an implementation and is not bound to a particular programming language).

The essence of Design Patterns consists of the following six rules:

  1. They are tried-and-true solutions: Because developers often use Design Patterns, we may be confident that they function. Not only that, but we can also guarantee that they were altered several times and that optimizations were most likely performed.

  2. They are simple to re-use: Design Patterns describe a reusable solution that may modify to solve various specific situations because they aren't tied to a specific situation.

    Consider the Iterator Design Pattern, reusable across STL despite container and algorithm changes. Iterators act as a glue between the container and the algorithm.

  3. They have a strong personalities: Design Patterns may elegantly describe a considerable solution. The Visitor pattern, for example, is used to perform a new operation on a range/group of classes. As a result, the standard library adopted this design with a single function, namely the std::visit algorithm. The same is true for boost::flyweight.

  4. They facilitate communication: Developers' knowledge about Design Patterns can communicate more readily about potential solutions to a given challenge.

    If we're part of a team of developers, agree on Design Patterns with our colleagues since they can help us solve problems more effectively. We should also follow similar practices for software maintenance, as it makes maintenance operations faster and more efficient.

  5. They eliminate the need for code refactoring: When an application is created with Design Patterns in mind, we may not need to rewrite the code later since applying the relevant Design Pattern to a specific problem is already an optimum solution.

    If such solutions are later updated, they may be applied effortlessly by any excellent software developer without causing any complications.

  6. They reduce the codebase's size: Design Patterns use less code than alternative solutions since they are generally beautiful and optimal. This isn't always the case, because many developers add extra code to improve understanding.

Types of Design Patterns

Design Patterns are divided into the following three categories.

Creational

Class instantiation or object generation is the focus of these Design Patterns.

Class-creational patterns and object-creational patterns are two subsets of these patterns. While class-creation patterns make good use of inheritance in the instantiation process, object-creation patterns use delegation.

Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype are creational Design Patterns.

Use Case of Creational Design Patterns

  1. Assume a programmer wants to create a simple DBConnection class to connect to a database and needs to use the database from code in numerous places. The developer will typically create an instance of the DBConnection class and use it to perform database operations wherever they are needed. As each example of the DBConnection class has a different connection to the database, numerous connections to the database are created. To deal with it, we make the DBConnection class a singleton class, which means that only one instance of DBConnection is generated, and only one connection is made. We can control load balance, redundant connections, and so on since we can manage DBConnection from a single instance.
  2. We can use the Factory design if we wish to create several instances of the same type while maintaining loose coupling. A factory-Design Pattern-implemented class acts as a link between numerous classes – for instance, the use of various database servers such as SQL Server and Oracle. We should use the Factory Design Pattern to achieve loose coupling and create a similar kind of object if we are developing an application with a SQL Server database as the back end. Still, if we need to change the database to Oracle, we will need to modify all of our code. Hence, as Factory Design Patterns maintain loose coupling and easy implementation, we should use the factory layout design to achieve loose coupling and create a similar kind of object.
Structural

These Design Patterns deal with grouping distinct classes and objects together to create larger structures and add new functionality.

Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy are structural Design Patterns.

Use Case of Structural Design Patterns

  1. An Adapter Design Pattern is used when two interfaces are incompatible and want to establish a relationship between them using an adapter. The adapter pattern transforms a class’s interface into another interface or class that the client expects, allowing classes that would otherwise be incompatible with operating together. We can use the adapter pattern in these types of incompatible instances.
Behavioral

Identifying and discovering shared communication patterns between items are all about behavioral patterns.

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Scheme, Template method, and Visitor are behavioral patterns.

What Exactly is the Gang of Four (GOF)?

The book Design Patterns: Elements of Reusable Object-Oriented Software, written by four writers, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, was published in 1994 and introduced the first concept of Design Patterns in software development.

Gang of Four is the collective name for these four authors (GOF). According to these authors, Design Patterns are essentially based on the following object-oriented design principles:

  1. Not an implementation, but to program to an interface.
  2. Object composition should take precedence over inheritance.