Design patterns summary

SOLID design principles
Single Responsibility Principle (SRP)	Ensuring a class has only one primary responsibility, and it mustn't have more.
Open/Closed Principle (OCP)	Allowing software entities to be open for extension but closed for modification.
Liskov Substitution Principle (LSP)	Ensuring subtypes can replace their base types without altering behavior.
Interface Segregation Principle (ISP)	Avoiding forcing clients to depend on interfaces they do not use.
Dependency Inversion Principle (DIP)	Decoupling high-level modules from low-level modules by depending on abstractions.
Creational design patterns
Builder	Constructing complex objects step by step, improving readability and flexibility.
Factories	Allowing the creation of alternative constructors, often with more descriptive names or specialized logic for object creation, while keeping the main `__init__()` constructor simple. Factory Method allows subclasses to define the type of object to be created, enabling customization of object creation without modifying the core logic. Abstract Factories define how Factories should be implemented.
Prototype	Creating new objects by copying an existing instance instead of building from scratch.
Singleton	Ensuring only one instance of a class exists and providing a global access point.
Monostate	A Singleton variation where multiple instances share the same state.
Lazy Initialization	Delaying object creation until it is actually needed, optimizing resource usage.
Dependency Injection	Passing dependencies to objects rather than creating them internally, improving flexibility.
Structural design patterns
Adapter	Allowing incompatible interfaces to work together by translating requests.
Bridge	Separating abstraction from implementation, allowing them to vary independently.
Composite	Treating individual objects and compositions of objects uniformly.
Decorator	Dynamically adding behavior to an object without modifying its structure.
Facade	Providing a simplified interface to a larger and more complex system.
Flyweight	Minimizing memory usage by sharing objects instead of creating new ones.
Proxy	Controlling access to an object by acting as an intermediary.
Behavioral design patterns
Observer	Defining a dependency where multiple objects listen for changes in another object.
Chain of Responsibility	Passing requests along a chain of handlers, allowing dynamic handling.
Command	Encapsulating requests (actions) as objects, allowing parameterization of objects. It is also useful for implementing the undo functionality.
Interpreter	Defining a grammar and an interpreter to process expressions in that language.
Iterator	Providing a way to sequentially access elements of a collection without exposing its structure.
Mediator	Reducing direct communication between objects by introducing a mediator object.
Memento	Capturing and restoring an object's state without violating encapsulation.
State	Allowing an object to change behavior when its internal state changes.
Strategy	Encapsulating algorithms in separate classes and allowing dynamic selection.
Template Method	Defining the program skeleton while allowing subclasses to fill in specific steps.
Visitor	Separating algorithms from object structures, allowing new operations without modifying classes.

Model-View-Controller (MVC)

Model-View-Controller is a software architectural pattern used to separate concerns in application development. It divides an application into three interconnected components, improving organization, scalability, and maintainability. It is not a design pattern.

Model – manages the data and business logic (e.g., fetching user info from a database).
View – handles the user interface and presentation (e.g., displaying the user’s name).
Controller – processes user input, updates the model, and selects the view to render (e.g., handling a login click).