# The 23 Design Patterns by GoF

## Links
- [The 23 well-known GoF design pattern](https://buihuycuong.medium.com/the-23-gang-of-four-design-patterns-974ae8d1a957)
- [Design Pattern 系列文](https://waynecheng.coderbridge.io/2021/01/09/DesignPattern-Preface/)
- [Design Pattern 鐵人賽](https://ithelp.ithome.com.tw/articles/10216587)

以下圖片來自 [大話設計模式](https://github.com/3masterplus/book/blob/master/%E5%A4%A7%E8%AF%9D%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F(%E5%B8%A6%E7%9B%AE%E5%BD%95%E5%AE%8C%E6%95%B4%E7%89%88).pdf)。

## UML Class Diagram
### Dependency (Use-a)
- Briefly interacts, use its function and maybe only once
- Do not hold reference

### Association (Has-a)
- Mostly used
- Association Qualifier (Hash Table, IRS + Tax ID <-> Person)
- Hold a reference of each other, interact in a given period of time

### Aggregation (Owns-a, Your things -> You)
- Recursive case: with base node
- If one of them is missing, another might be unaffected
- Actively Instantiate (Compared to Association)

### Composition (Is-part-of-a, Hand -> You)
- Strong and seldomly used
- If one of them is missing, then the other one will be missing as well
- Need to be responsible for life cycle of its component

### Generalization (Is-a, Animal <- Cat)
- Inheritance relationship

## Design Process from J Lee
Encapsulation, Abstraction, Delegation
- Encapsulation: Encapsulate what varies
- Abstraction: Program to an interface, not to implementation
- Delegation: Depend on Abstraction, not on concrete class

## Introduction
The Gang of Four (GoF) design patterns refer to the 23 design patterns introduced in the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. These patterns are categorized into three main groups based on their purpose:

## Categories
1. Creational Patterns: These patterns deal with the process of object creation, trying to make the creation process more flexible and dynamic.

* Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
* Builder: Separates the construction of a complex object from its representation, allowing the same construction process to create different representations.
* Factory Method: Defines an interface for creating objects, but lets subclasses alter the type of objects that will be created.
* Prototype: Creates new objects by copying an existing object (the prototype).
* Singleton: Ensures that a class has only one instance and provides a global point of access to it.

2. Structural Patterns: These patterns are concerned with the composition of classes or objects to form larger structures, focusing on how to ensure relationships between entities are maintained.

* Adapter: Allows incompatible interfaces to work together by converting one interface to another that a client expects.
* Bridge: Decouples an abstraction from its implementation so that the two can vary independently.
* Composite: Composes objects into tree-like structures to represent part-whole hierarchies.
* Decorator: Attaches additional responsibilities to an object dynamically, without affecting other objects of the same class.
* Facade: Provides a simplified interface to a complex subsystem of classes.
* Flyweight: Uses sharing to support large numbers of fine-grained objects efficiently.
* Proxy: Provides a surrogate or placeholder for another object to control access to it.

3. Behavioral Patterns: These patterns are concerned with communication between objects, focusing on the interaction and responsibilities between them.

* Chain of Responsibility: Allows a request to be passed along a chain of handlers until one of them handles it.
* Command: Encapsulates a request as an object, allowing parameterization of clients with queues, requests, and operations.
* Interpreter: Implements a specialized language and interprets sentences of that language.
* Iterator: Provides a way to access elements of an aggregate object sequentially without exposing its underlying representation.
* Mediator: Defines an object that controls how a set of objects interact, centralizing communication.
* Memento: Captures the internal state of an object without exposing its implementation, allowing it to be restored later.
* Observer: Defines a one-to-many dependency, so when one object changes state, all its dependents are notified and updated automatically.
* State: Allows an object to alter its behavior when its internal state changes, making it appear as if the object changed its class.
* Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable.
* Template Method: Defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm.
* Visitor: Allows you to define new operations on elements of an object structure without changing the elements themselves.

## Summary of GoF 23 Patterns
* Creational Patterns: Deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.
* Structural Patterns: Deal with the composition of classes and objects, focusing on how to make larger structures more flexible.
* Behavioral Patterns: Deal with the interaction between objects, focusing on how responsibilities are distributed and how objects collaborate.

These patterns provide well-established solutions for common design problems, making it easier to create reusable, maintainable, and scalable software systems.

# SOLID
* Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should only have one job or responsibility.
* Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification, allowing behavior changes without altering existing code.
* Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without altering the correctness of the program.
* Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use, favoring smaller, specific interfaces over large, general-purpose ones.
* Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions to promote loose coupling.

# Others
* Law of Demeter
* Composition/Aggregate Reuse Principle (CARP)