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 these design patterns were divided into 3 categories. introduced 23 design patterns, 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. . 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. Design patterns are not algorithms or code 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 “ Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.” The strategy pattern (also known as the policy pattern) is a behavioural software design pattern that enables selecting an algorithm at runtime. 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, because typically, composition leads to a more flexible design. if you have a choice, use composition rather than inheritance The Adapter Pattern The Adapter Pattern is used to convert the interface of a class into another interface that clients expect. . So, this pattern’s going to give us a way to have two classes work together when they have incompatible interfaces. The adapter lets classes work together that couldn’t otherwise because of 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 . 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 Design pattern is basically a publisher-subscriber relationship 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, (Array, Arraylist..). Iterator Pattern, allows you to pull out iteration logic in the iterator and that iterator can be used by different collections 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

Chain

10 Best Practices for Every React Developer

Going From Zero to Transpiling your First App in TypeScript 

Nominated for 2022 - HackerNoon Contributor of the Year - Product Development

Nominated for 2022 - HackerNoon Contributor of the Year - Microservices

Nominated for 2022 - HackerNoon Contributor of the Year - React

Nominated for 2022 - HackerNoon Contributor of the Year - Frontend

Nominated for 2022 - HackerNoon Contributor of the Year - Best Practices

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Too Long; Didn't Read

Make resilience your competitive advantage

Software Design Patterns Explained

Software Design Patterns Explained

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Best Practices for Every React Developer

Optimizing Elastic Search for High-Load Applications

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

10 Best Practices for Every React Developer

Optimizing Elastic Search for High-Load Applications

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps