Iniziamo. È gratuito!
o registrati con il tuo indirizzo email
Design patterns da Mind Map: Design patterns

1. Creational patterns

1.1. Singleton

1.1.1. Intent

1.1.1.1. Only one instance

1.1.1.2. Global access to this instance

1.1.2. Problem

1.1.2.1. Manages the creation and maintenance of a single instance (object creation, control of number of instances)

1.1.2.2. Provides a global access point to use that instance

1.1.3. Solution

1.1.3.1. Make constructor private, prevent using the new operator

1.1.3.2. Create a static method to get that instance

1.1.4. Pros

1.1.4.1. Only a single instance

1.1.4.2. Global access point to that instance

1.1.4.3. Initialized 1 time for the first requested

1.1.5. Cons

1.1.5.1. Single responsibility principle

1.1.5.2. Masking bad design

1.1.5.3. Special treatment in multithreaded enviroments

1.1.5.4. Difficult to unit test

1.2. Factory methods

1.2.1. Intent

1.2.1.1. Provides an interface for creating objects in the parent class

1.2.1.2. Allows child classes to decide what type of object will be created

1.2.2. Problem

1.2.2.1. Code depends on specific class

1.2.2.2. Adding new logic requires many fixes

1.2.2.3. Code gradually becomes confusing with many if/else, switch-case

1.2.2.4. Need to separate object creation logic for flexible expansion

1.2.3. Solution

1.2.3.1. Separates initialization logic from usage logic, allowing changes to the type of objects created without changing client code

1.2.4. Props

1.2.4.1. Factory Method helps reduce dependencies, separate object creation logic, and is easy to extend without affecting running code.

1.2.5. Cons

1.2.5.1. Make code complicated by having to create many subclasses

2. Structural patterns

2.1. Decorator

2.1.1. Intent

2.1.1.1. Attach new behaviors to objects by placing these objects inside wrapper objects that contain the behaviors

2.1.2. Problem

2.1.2.1. When the system needs to extend functionality, inheritance to create subclasses for each case will lead to class explosion, making the code complex and difficult to maintain

2.1.3. Solution

2.1.3.1. Use composition to extend object behavior flexibly, by wrapping multiple "wrapper" classes that adhere to the same interface

2.1.4. Pros

2.1.4.1. Extend object behavior without creating subclasses

2.1.4.2. Add or remove functionality at runtime flexibly

2.1.4.3. Combine multiple behaviors by wrapping multiple decorator classes

2.1.4.4. Follow the single responsibility principle (SRP)

2.1.5. Cons

2.1.5.1. Difficult to remove a specific decorator class in a chain

2.1.5.2. Behavior depends on the wrapping order, which is error-prone

2.1.5.3. Initial initialization code can be confusing and difficult to read

2.2. Proxy

2.2.1. Intent

2.2.1.1. Create a replacement or proxy for another object

2.2.1.2. Control access to the original object

2.2.2. Problem

2.2.2.1. Need a way to control access to heavy objects without modifying the original code and avoiding duplicate lazy load logic

2.2.3. Solution

2.2.3.1. Create a new proxy class that has the same interface as the original object. Your application will use the proxy object instead of the real object.

2.2.4. Pros

2.2.4.1. Control access to real objects without the client knowing

2.2.4.2. Flexible object creation and lifecycle management

2.2.4.3. Works even when the original object is not ready

2.2.4.4. Easy to extend, no need to modify the original code or the client

2.2.5. Cons

2.2.5.1. Increased complexity due to additional layers

2.2.5.2. May cause delays due to indirect processing via proxy

3. Behavioral patterns

3.1. Observer

3.1.1. Intent

3.1.1.1. Allows an object (subject) to automatically notify multiple other objects (observers) when its state changes.

3.1.2. Problem

3.1.2.1. There is no efficient way to notify only the right people when a change occurs, causing waste for both the store and the customer

3.1.3. Solution

3.1.3.1. The object with important state is called Publisher (Subject)

3.1.3.1.1. List of subscribers

3.1.3.1.2. Methods to add and remove subscribers.

3.1.3.1.3. When an event occurs, the publisher will call the notification function on each subcriber

3.1.3.2. The objects that want to monitor it are called Subscribers (Observers).

3.1.4. Props

3.1.4.1. Easily add new subscribers without modifying publishers

3.1.4.2. Can connect publishers and subscribers at runtime

3.1.5. Cons

3.1.5.1. Subscribers are notified in random order