Posted on

Design Patterns

Creational Pattern

Abstract Factory – allows the creation of objects without specifying their concrete type
Builder – uses to create complex objects
Factory Method – creates objects without specifying the exact class to create
Prototype – creates a new object from an existing object
Singleton – ensures only one instance of an object is created

Structural Pattern

Adapter – allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.
Bridge – decouples an abstraction so two classes can vary independently.
Composite – takes a group of objects into a single object.
Decorator – allows for an object’s behavior to be extended dynamically at run time.
Facade – provides a simple interface to a more complex underlying object.
Flyweight – reduces the cost of complex object models.
Proxy – provides a placeholder interface to an underlying object to control access, reduce cost, or reduce complexity.

Behavioral Pattern

Chain of Responsibility – delegates commands to a chain of processing objects.
Command – creates objects which encapsulate actions and parameters.
Interpreter – implements a specialized language.
Iterator – accesses the elements of an object sequentially without exposing its underlying representation.
Mediator – allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
Memento – provides the ability to restore an object to its previous state.
Observer – is a publish/subscribe pattern which allows a number of observer objects to see an event.
State – allows an object to alter its behavior when its internal state changes.
Strategy – allows one of a family of algorithms to be selected on-the-fly at run-time.
Template Method – defines the skeleton of an algorithm as an abstract class, allowing its sub-classes to provide concrete behavior.
Visitor – separates an algorithm from an object structure by moving the hierarchy of methods into one object.

 

Posted on

SOLID

Single-responsibility principle
A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.

Open–closed principle
“Software entities … should be open for extension, but closed for modification.”

Liskov substitution principle
“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

Interface segregation principle
“Many client-specific interfaces are better than one general-purpose interface.”

Dependency inversion principle
One should “depend upon abstractions, [not] concretions.”

https://en.wikipedia.org/wiki/SOLID
https://medium.com/@mari_azevedo/s-o-l-i-d-principles-what-are-they-and-why-projects-should-use-them-50b85e4aa8b6