Protocol-Oriented Programming with Swift

The observer pattern is used to implement distributed event handling where an observer type is notified when an event occurs within another type. The observer pattern allows groups of objects to cooperate with one another with few dependencies between them. This pattern is so widely used that you have probably come across it many times if you have developed applications using any modern UI framework such as Cocoa or Cocoa Touch.

The strategy pattern is really good for setting the algorithms to use at runtime, which also lets us swap the algorithms out with different implementations as needed by the application. Another advantage of the strategy pattern is that, we encapsulate the details of the algorithm within the strategy types themselves and not in the main implementation type.

The strategy pattern is pretty similar to the command pattern in that they both allow us to decouple implementation details from our calling type and also allow us to switch the implementation out at runtime. The big difference is, the strategy pattern is intended to encapsulate algorithms. By swapping out an algorithm, we are expecting the object to perform the same functionality but in a different way.

There are times in our applications when we need to separate the execution of a command from its invoker. Typically, this is when we have a type that needs to perform one of several actions; however, the choice of which action to use needs to be made at run-time

Chain of responsibility: This is used to process a variety of requests, each of which may be delegated to a different handler.
Command: This creates objects that can encapsulate actions or parameters so they can be invoked later or by a different component.
Iterator: This allows us to access the elements of an object sequentially without exposing the underlying structure.
Mediator: This is used to reduce coupling between types that communicate with each other.
Memento: This is used to capture the current state of an object and store it in a manner that can be restored later.
Observer: This allows an object to publish changes to its state. Other objects can then subscribe so they can be notified of any changes.
State: This is used to alter the behavior of an object when its internal state changes.
Strategy: This allows one out of a family of algorithms to be chosen at runtime.
Visitor: This is a way of separating an algorithm from an object structure

The proxy pattern is very useful when we want to add some additional functionality or error checking to a type, but we do not want to change the actual type itself. We can also use it to add a layer of abstraction between a remote or local API.

In the proxy design pattern, there is one type acting as an interface for another type or API.

The façade pattern provides a simplified interface to a larger and more complex body of code. This allows us to make our libraries easier to use and understand by hiding some of the complexities. It also allows us to combine multiple API's into a single, easier to use, API, which is what we will see in our example

The bridge pattern tells us that, when we have two hierarchies that closely interact together like this, we should put this interaction logic into a bridge type that will encapsulate the logic in one spot.

Adapter: This allows types with incompatible interfaces to work together
Bridge: This is used to separate the abstract elements of a type from the implementation so the two can vary
Composite: This allows us to treat a group of objects as a single object
Decorator: This lets us add or override behavior in an existing method of an object
Façade: This provides a simplified interface for a larger and more complex body of code
Flyweight: This allows us to reduce the resources needed to create and use a large number of similar objects
Proxy: This is a type acting as an interface for another class or classes