Software Design Patterns Explained

Design patterns are reusable and effective solutions for common software design problems.

Design patterns provide paths to solutions for some of the most common object-oriented design conundrums. They’re solutions developed over time through trial and error that are well-documented and can be applied to the specific design problems

Design patterns were first described in the book Design Patterns: Elements of Reusable Object-Oriented Software Design. This book was written by four software engineers. And they introduced 23 design patterns, these design patterns were divided into 3 categories.

Creational

• Abstract factory

• Builder

• Factory method

• Prototype

• Singleton

  
  

Structural

• Adapter

• Bridge

• Composite

• Decorator

• Facade

• Flyweight

• Proxy

  
  

Behavioral

• Chain of responsibility

• Command

• Interpreter

• Iterator

• Mediator

• Memento

• Observer

• State

• Strategy

• Template method

• Visitor

  
  

Design patterns will often help you to create software that will be resilient to change.

Design patterns are not algorithms or code. A design pattern is an approach to thinking about software design that incorporates the experience of developers who’ve had similar problems, as well as fundamental design principles that guide how we structure software designs.

A design pattern is usually expressed by a definition, a class diagram, and collected into a catalogue of patterns.

Design principles and Design patterns, Are they the same?

No,

Design principles( Encapsulation, Inheritance etc ) and Design patterns are different. Principles are general guidelines while patterns are specific design solutions often aimed at solving common object-oriented problems. Design patterns are comprised of object-oriented basics.

Let’s discuss a few design patterns

Strategy pattern

The strategy pattern defines a family of algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Now, this definition doesn’t tell us how to implement the pattern, but it does give us a good idea of the intent of a pattern.

As per wiki

“The strategy pattern (also known as the policy pattern) is a behavioural software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.”

                                                                   wiki/Strategy_pattern

For example, A class that performs validation on incoming data may use the strategy pattern to select a validation algorithm depending on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known until run-time and may require radically different validation to be performed.

This idea, of using composition(HAS-A) rather than inheritance(IS-A), is another important design principle. This principle says, if you have a choice, use composition rather than inheritance because typically, composition leads to a more flexible design.

The Adapter Pattern

The Adapter Pattern is used to convert the interface of a class into another interface that clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. So, this pattern’s going to give us a way to have two classes work together when they have incompatible interfaces.

The adaptor sits in the middle of the client and the adaptee and delegates the client’s calls to the adapted.

The advantage of the adapter pattern is that you can add an adapter easily without having to modify the adaptee at all and only modify the client to add the adapter. Say you have a vendor class that you can’t modify and it uses a different interface than you expect, but you need to make the vendor class work with your system. Well, the adapter pattern makes this easy.

The Observer Pattern

The Observer Design pattern is basically a publisher-subscriber relationship. Any object can send a request to subscribe to the publisher object. When the request is received by the publisher, the requesting object immediately becomes a subscriber.

The observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

The observers are free to add themselves to the list at any time, they can also remove themselves, or even be replaced by another observer at any time. The subject just doesn’t care. All it does is maintain a list and notify the objects on that list as necessary.

The open-closed design principle says that classes/codes should be open for extension but closed for modification.

This principle and composition open the way for another design, let’s discuss it.

The Decorator Pattern

The decorator pattern attaches additional responsibilities to an object dynamically.

Decorators provide a flexible alternative to subclassing for extending functionality.

The Iterator Pattern

We have many ways to store collections of objects in data structures. For example, most modern programming languages provide arrays. If you’re using Java, you could store menu items for a menu in an array.

Most languages provide additional structures for storing collections of objects like lists, dictionaries and sets. For example, Java provides an ArrayList, which is a lot like an array, but has some list like capabilities too. Here we’re storing our menu items in an ArrayList. Simple enough, but what if we need to write code that operates over several of these collection types?

Is there a way that we can avoid rewriting the iteration code if we change our collection type?

The iterator pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

In simple words, Iterator Pattern, allows you to pull out iteration logic in the iterator and that iterator can be used by different collections(Array, Arraylist..).

The Factory Patterns

Factory allows us to decouple the process of creating objects from the clients that use those objects.

This pattern defines an interface for creating an object but lets subclasses decide which classes to instantiate.

Factory pattern encapsulates the implementation details and underlying implementation can be changed without any impact on main implementation .

It’s better to create a factory when you need to create complex products and you want an increased level of encapsulation, Factory pattern makes our code more robust, less coupled and easy to extend.

In this article, I shared some basic concepts about design patterns and how it works in general. In upcoming articles, we will be discussing these in detail. There is a very important thing I want to tell you at the end is,

You don’t have to use design patterns in a place where it’s not needed. Try to keep the solution as simple as possible. Here simplicity is key, Adding design patterns in a place where it’s not needed can increase the complexity and it can make your system inefficient.

I hope this article helped you to learn about a few design patterns and their benefits and drawbacks.

Also published here

https://ruchika-mourya.medium.com/software-design-patterns-4f16b2b43f20