Observer Patternmore_vert

Addy Osmani's Explanation

Observer Patternclose

The Observer is a design pattern in which an object (known as a subject) maintains a list of objects depending on it (observers), automatically notifying them of any changes to state. When a subject needs to notify observers about something interesting happening, it broadcasts a notification to the observers (which can include specific data related to the topic of the notification). When we no longer wish for a particular observer to be notified of changes by the subject it is registered with, the subject can remove it from the list of observers.

State Patternmore_vert

Wikipedia Explanation

State Patternclose

It is a behavioural design pattern that allows an object to alter its behaviour based on changes to its internal state. The object returned by a state pattern class seems to change its class. It provides state-specific logic to a limited set of objects in which each object type represents a particular state.

Chain of Responsibility Patternmore_vert

Addy Osmani's Explanation

Chain of Responsibility Patternclose

The Chain of Responsibility design pattern separates the sender of a request from the receiver. This avoids coupling of the requester and receiver. Further, the pattern allows a request to be passed along a chain to several different objects that have an opportunity to handle the request. The sender doesn’t need to know which object handles the request, and the object doesn’t need to know who sent the request. There’s no coupling between the two.

Iterator Patternmore_vert

Addy Osmani's Explanation

Iterator Patternclose

The Iterator is a design pattern in which iterators (objects that allow us to traverse through all the elements of a collection) access the elements of an aggregate object sequentially without needing to expose its underlying form. Iterators encapsulate the internal structure of how that particular iteration occurs.

Strategy Patternmore_vert

Explanation

Strategy Patternclose

The Strategy pattern encapsulates alternative algorithms (or strategies) for a particular task. It allows a method to be swapped out at runtime by any other method (strategy) without the client realizing it. Essentially, Strategy is a group of algorithms that are interchangeable. Compared to factory pattern as a creational pattern, strategy pattern is an operational pattern. Put another way, a factory pattern is used to create objects of a specific type. A strategy pattern is use to perform an operation (or set of operations) in a particular manner.

Memento Patternmore_vert

Explanation

Memento Patternclose

The Memento pattern provides temporary storage as well as restoration of an object. The mechanism in which you store the object’s state depends on the required duration of persistence, which may vary. You could view a database as an implementation of the Memento design pattern in which objects are persisted and restored. However, the most common reason for using this pattern is to capture a snapshot of an object’s state so that any subsequent changes can be undone easily if necessary. Essentially, a Memento is a small repository that stores an object’s state. Scenarios in which you may want to restore an object into a state that existed previously include: saving and restoring the state of a player in a computer game or the implementation of an undo operation in a database. In JavaScript Mementos are easily implemented by serializing and de-serializing objects with JSON.

Mediator Patternmore_vert

Addy Osmani's Explanation

Mediator Patternclose

The Mediator is a behavioral design pattern that allows us to expose a unified interface through which the different parts of a system may communicate. The Mediator pattern promotes loose coupling by ensuring that instead of components referring to each other explicitly, their interaction is handled through this central point. This can help us decouple systems and improve the potential for component reusability. A centralized controller is key to the success of this system, and that’s really the role that the Mediator plays in software design

Command Patternmore_vert

Addy Osmani's Explanation

Command Patternclose

The Command pattern aims to encapsulate method invocation, requests, or operations into a single object and gives us the ability to both parameterize and pass method calls around that can be executed at our discretion. In addition, it enables us to decouple objects invoking the action from the objects that implement them, giving us a greater degree of overall flexibility in swapping out concrete classes (objects). The general idea behind the Command pattern is that it provides us a means to separate the responsibilities of issuing commands from anything executing commands, delegating this responsibility to different objects instead.