Design patterns

Factory method pattern

• It defines an interface for creating an object, but it let’s the subclasses decide which class to instantiate.

• Usage: We give the object creation logic and responsibility to the subclass factories. This way we don’t control instantiation from the client code.

Abstract factory pattern

• it defines an interface for creating families of object groups without knowing their specific type.

• example: menu: soup with main dish

Prototype pattern

• create object by copying an already existing prototype not by instantiating a class.

• You don’t need to know the exact type to create an instance, and can avoid instantiation complexity. Copy instead of instantiate

• java Cloneable interface.

Builder pattern

• separate the process of complex object construction from it’s representation. Same process can produce different results.

• → multiple builders can use the same process but produce different formats: json, xml…

Singleton pattern

• ensures that a class has only one instance and provides an entry point to it.

• implementation: make constructor final and a public static synchronized method as a getter for the instance

Proxy pattern

• provides a placeholder for another object to control access to it.

• implementation: client calls the proxy(placeholder), proxy does some operations and then calls the original object. The proxy and the original object implement the same interface → the client doesn’t see any difference.

• usage: access validation - security, testing

• it’s similar to the decorator patten but the goal is to control access to an object, not to add additional functionality

Decorator pattern

• adds additional functionality to the original object dynamically by wrapping it. It’s an alternative to subclassing

• implementation: implement the same interface/abstract class with the wrapper + add the original object as an attribute.

Adapter pattern

It resolves the interface of a class to another interface that the client needs.

types:

• object adapter: the adapter class takes the interface that needs to be converted as an attribute and implements the interface that the client needs

• class adapter: CustomAdapter extends ConvertableClass implements ClientInterface

Usually objectadapter is used.

Facade pattern

Provides a a high level simplified API to a complex subsystem hiding internal complexity from clients.

Flyweight pattern

Improves memory efficiency by sharing intrinsic attributes between objects and separating from them the extrinsic attributes that vary by object.

Composite pattern

Composes objects into tree hierarchy where an object and a group of objects can be treated uniformly by the client.

Bridge pattern

• Decouple abstractions from their implementations so the implementations can vary independently.

• More understandable definition: you have 2 abstractions and their implementations will vary independently. One of the implementation will get the other as an attribute: composite dependency.

• Example: notification(alert, reminder) + sender(email, sms)

Template method pattern

• Defines the skeleton of the algorithm in the base class and makes some steps customizable in the subclasses. The subclasses cannot change the overall structure, they can only customize it!

• example: BaseClass defines default operations, and they use the logger provided by the subclasses.

Observer pattern

• It defines a one to many relationship: When the subjects state changes, all the dependents(subscribers) are notified.

• Implementation: Observer, Subject interfaces → subject can register, unregister observers, and when it updates state, it calls the observers notifyObserver() method;

Chain of responsibility pattern

• It decouples the sender of a request from the receiver. There are multiple receivers that can handle a request, and they are chained. The request is forwarded in the receiver chain until one of them handles it.

• implementation: RequestHandler interface with nextHandler(RequestHandler) and handleRequest(Request req) methods

• example: ticket handling

Iterator pattern

• Access aggregate object elements sequentially, without exposing the underlying data structure.

• Implementation: Iterator interface with hasNext(), getNext() methods, built in: Iterator<T>

Command pattern

Wraps actions into objects, decouples sender from receiver. → support undo/redo + action history + queue requests. Important parts: receiver, command, commandHandler, client

• Command interface implemented by Commands → invoke receiver methods. CommandHandler receives and executes Commands + undo/redo/history…

Memento pattern

Captures an objects state so it can be restored later → provides an object state history. Important components: Memento, Originator(original object), caretaker/client

• memento: state of the originator without behavior

• caretaker: saves mementos and loads originators state

Strategy pattern

• Decouples behavior(algorithm) from the object. The object can behave differently by setting a different behavior.

• Parts: Object, Behavior interface + impl, Manager with behavior attribute that can run the behavior on the object. The manager can check player state before setting behavior → validation, more control

• Example: player can fly, run, stand still.