Kush's Blog

Kush's Blog

Design Patterns

Design Patterns

A design pattern provides a general reusable solution for the common problems that occur in software design. The pattern typically shows relationships and interactions between classes or objects.

Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

What is the need of Design Patterns

  • Design patterns can speed up the development process by providing tested, proven development paradigms.

  • Effective software design requires considering issues that may not become visible until later in the implementation.

  • Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

designPatterns.JPG

The Gang of Four categorized their 23 Design Patterns in three groups, namely -

  • Creational — They deal with the creation of objects. Singleton & Factory are examples of creational design patterns.

  • Structural — They deal with the relationship between the objects. Adapter is an example of structural design patterns.

  • Behavioral — They deal with interaction & communication between the objects. Strategy is an example of behavioral design patterns.

Top popular software design patterns

Singleton

singleton.JPG

One of the most used design patterns, Singleton makes sure that only one instance of a particular class is created, and provides a global point of access to that instance.

Singleton is most useful when you need a single object to coordinate other objects.

A singleton is usually implemented as a class that contains:

  • a private constructor (so that only members of the same class can access it),
  • a private static member,
  • a static public method that returns a reference to the private static member.

Strategy Pattern

strategy.JPG

This design pattern allows you to select algorithm/logic at runtime. For example, your program needs to pick the kind of Sorting algorithm it needs to use based on some logic.

Adapter Pattern

adapter.JPG

This design pattern works to connect two incompatible interfaces, that cannot be connected. It wraps an existing class in a new interface to make it compatible with client interface.

Factory Pattern

factory.JPG

This pattern allows the creation of objects without having to specify the exact class of the object. A normal factory produces goods; a software factory produces objects. And not just that it does so without specifying the exact class of the object to be created. To accomplish this, objects are created by calling a factory method instead of calling a constructor.

State

state.JPG

The state pattern encapsulates the various states a machine can be in, and allows an object to alter its behavior when its internal state changes. The machine or the context, as it is called in pattern-speak, can have actions taken on it that propel it into different states. Without the use of the pattern, the code becomes inflexible and littered with if-else conditionals.

Proxy Pattern

proxy.JPG

In the Proxy pattern, a class functions as an interface to ‘something’. This ‘something’ could be a network request to get JSON response from a REST API or could be getting the JSON response from the locally cached Database.

AntiPatterns

AntiPatterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations. A higher-level vocabulary simplifies communication between software practitioners and enables concise description of higher-level concepts.

An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context.

AntiPatterns provide real-world experience in recognizing recurring problems in the software industry and provide a detailed remedy for the most common predicaments.

Interested in reading more such articles from Kushagra Sharma?

Support the author by donating an amount of your choice.