SOLID

Because of SOLID programmers can develop more modular/elastic systems.

• SRP, Single Responsibility Principle
• Class should have only one responsibility and one reason for the change.

• Open-Closed Principle
• Class should be open for extensions, but close for modifications.

• Liskov Substitution Principle
• A child class should be able to do everything the parent class can do, without changing the expected behavior.
• Subclasses can change/extend interface already defined, but it should be done in a way that not break base class contract.
• Subclasses should be compliant with expectation coming from base class users. They should not surprise users.

• ISP, Interface segregation principle
• It says about creating more precise, specialized interfaces.
• Interfaces should be split to smaller, more precise interfaces.
• Classes should not be forced to implement not needed methods.

• DIP, Dependency inversion principle
• DIP is all about reversing the traditional dependency relationship:
• High-level business logic should rely on abstractions.
• Low-level modules provide concrete implementations of those abstractions.
• This results in more flexible, modular, and maintainable code that’s easier to extend and test.

INTRO:

• Creational Patterns (deals with object creation mechanisms)
• Singleton, Factory, Builder
• Structural Patterns (deals with object composition and structure)
• Adapter, Facade, Proxy
• Behavioral Patterns (deals with object communication and responsibility)
• Observer, Strategy, Command

• Decorator, Iterator, Context manager

• Singleton (configuration or connections management)
• Factory (objects are created dynamically)
• Adapter (library integrations)
• Observer (notifications, events)
• Facade (complex API simplifying)
• Decorator (extending functionalities in runtime)
• Builder (more complex objects)
• Proxy (lazy-loading, remote calls)
• Command (task queues)

---

REVIEWING DESIGN PATTERNS:

• Composition is a design principle in object-oriented programming where one class is composed of one or more objects from other classes.
• Composition is favored over inheritance when a "has-a" relationship makes more sense than an "is-a" relationship.
• Example

• It allows you to define different ways of doing something (strategies) and let the client choose which one to use at runtime.
• It is similar to Adapter because both plays as Proxy-Agent separating Client logic from detailed implementation. However, Strategy and Adapter in general have different goals.
• Strategy example
• Strategy design pattern consists of:
• Context - the class using the algorithm, but doesnt know how is implemented
• Strategy Interface - common interface for all Strategies that Context uses
• Concrete Strategies - specific Strategy implementations

• it is for creating One-to-Many dependency between objects
• when one object (Subject) changes own state then all dependant objects (Observers) are automatically notified and can update appropriately

• Decorator examples

• Adapter example
• Adapter design pattern is component translating things between incompatible interfaces
• It uses composition and activity delegation to achieve these goals

• It ensures that a class has only one instance and provides a global access point to that instance. It is used to manage a shared resource or state across the system, preventing the creation of multiple instances of the same class. Singleton is sometimes called anti-pattern. Whether it's beneficial or problematic depends on how and why it's used.
• Typical Use cases:
• Resource Management, Global Configuration, Logging
• Singleton logging example
• Key characteristics of the Singleton Pattern:
• Single Instance, Global Access, Lazy Initialization, Controlled Access

• MVC (Model View Controller)
• CQRS (Command Query Responsibility Segregation)
• Event Sourcing
• Hexagonal Architecture (Ports & Adapters)
• Example
• Clean Architecture (Robert C. Martin)
• DDD (Domain-Driven Design)
• Microservices architecture (How Django fits to it? Is not monolith approach?)