Software Design Patterns

A design pattern in software engineering is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be directly translated into code. It is a description or template for solving a problem that can be used in a variety of situations.

Uses of Design Patterns

Design patterns can help to accelerate the development process by providing tried-and-true development paradigms. Effective software design necessitates taking into account issues that may not become apparent until later in the implementation process. Reusing design patterns aids in the prevention of subtle issues that can lead to major problems and improves code readability for coders and architects who are familiar with the patterns.

People frequently only understand how to apply specific software design techniques to specific problems. These methods are difficult to apply to a wider range of problems. Design patterns provide general solutions that are documented in a format that does not necessitate specifics related to a specific problem.

Furthermore, patterns enable developers to communicate about software interactions by using well-known, well-understood names. Over time, common design patterns can be improved, making them more robust than ad hoc designs.

Creational design patterns

Class instantiation is central to these design patterns. This pattern is subdivided into class-creation patterns and object-creation patterns. While class-creation patterns effectively use inheritance in the instantiation process, object-creation patterns effectively use delegation.

• Abstract Factory
  Creates an instance of several families of classes
• Builder
  Separates object construction from its representation
• Factory Method
  Creates an instance of several derived classes
• Object Pool
  Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype
  A fully initialized instance to be copied or cloned
• Singleton
  A class of which only a single instance can exist

Structural design patterns

The composition of Classes and Objects is central to these design patterns. Inheritance is used to compose interfaces in structural class-creation patterns. Structural object-patterns define how objects can be combined to create new functionality.

• Adapter
  Match interfaces of different classes
• Bridge
  Separates an object’s interface from its implementation
• Composite
  A tree structure of simple and composite objects
• Decorator
  Add responsibilities to objects dynamically
• Facade
  A single class that represents an entire subsystem
• Flyweight
  A fine-grained instance used for efficient sharing
• Private Class Data
  Restricts accessor/mutator access
• Proxy
  An object representing another object

Behavioral design patterns

These design patterns are all about the communication of Class objects. Behavioral patterns are those that are specifically concerned with the communication of objects.

• Chain of responsibility
  A way of passing a request between a chain of objects
• Command
  Encapsulate a command request as an object
• Interpreter
  A way to include language elements in a program
• Iterator
  Sequentially access the elements of a collection
• Mediator
  Defines simplified communication between classes
• Memento
  Capture and restore an object’s internal state
• Null Object
  Designed to act as a default value of an object
• Observer
  A way of notifying change to a number of classes
• State
  Alter an object’s behavior when its state changes
• Strategy
  Encapsulates an algorithm inside a class
• Template method
  Defer the exact steps of an algorithm to a subclass
• Visitor
  Defines a new operation to a class without change

Criticism

Some in the field of computer science have criticized the concept of design patterns.

Targets the wrong problem

Patterns are required as a result of using computer languages or techniques with insufficient abstraction ability. A concept should not be copied, but rather referenced, according to ideal factoring. However, if something is referenced rather than copied, there is no “pattern” to label and catalogue. In his essay Revenge of the Nerds, Paul Graham writes.

Peter Norvig makes a similar case. He shows how in Lisp or Dylan, 16 of the 23 patterns in the Design Patterns book (which is primarily focused on C++) can be simplified or eliminated (via direct language support).

Lacks formal foundations

The study of design patterns has been excessively ad hoc, and some argue that the concept urgently needs to be formalized. The Gang of Four were subjected to a show trial at OOPSLA 1999 (with their full cooperation), in which they were “charged” with numerous crimes against computer science. They were “convicted” by 23 of the “jurors” who were present at the trial.

Leads to inefficient solutions

A design pattern is an attempt to standardize what are already widely accepted best practices. In theory, this appears to be beneficial, but in practice, it frequently results in unnecessary code duplication. Using a well-factored implementation rather than a “just barely good enough” design pattern is almost always a more efficient solution.

Does not differ significantly from other abstractions

Some authors argue that design patterns are not significantly different from other types of abstraction, and that using new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is cited as an example of a “pattern,” despite the fact that the concept of “design patterns” predates it by several years. Some argue that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexander’s pattern language as a form of documentation; a practice that is frequently overlooked in the literature.