By Ali Moradi AliDeWeb
- Encapsulation – Bundling data and methods within a class while restricting direct access to some details.
- Abstraction – Hiding complex implementation details and exposing only the necessary functionality.
- Inheritance – Allowing a class to inherit properties and behaviors from another class to promote code reuse.
- Polymorphism – Enabling multiple classes to be treated as instances of a common superclass, allowing method overriding and dynamic behavior.
- Single Responsibility Principle (SRP) – A class should have only one reason to change, meaning it should have only one responsibility.
- Open/Closed Principle (OCP) – Software entities should be open for extension but closed for modification.
- Liskov Substitution Principle (LSP) – Subtypes must be substitutable for their base types without altering the correctness of the program.
- Interface Segregation Principle (ISP) – Clients should not be forced to depend on interfaces they do not use.
- Dependency Inversion Principle (DIP) – High-level modules should not depend on low-level modules; both should depend on abstractions.
Apart from SOLID, other key design principles in OOP include:
- DRY (Don’t Repeat Yourself) – Avoid duplication by abstracting reusable code.
- KISS (Keep It Simple, Stupid) – Keep code simple and avoid unnecessary complexity.
- YAGNI (You Ain’t Gonna Need It) – Don’t implement features unless absolutely necessary.
- Law of Demeter (LoD) – Objects should only interact with closely related objects to reduce coupling.
These principles ensure maintainability, scalability, and clean code.
Design patterns are categorized into three main types:
These patterns focus on communication between objects and how they interact with each other.
- Observer – Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
- Strategy – Allows an object to change its behavior dynamically by switching between multiple algorithms.
- Command – Encapsulates a request as an object, allowing for parameterization of clients, queuing of requests, and logging of operations.
These patterns deal with the composition of classes and objects to form larger structures while keeping them flexible and efficient.
- Adapter – Bridges the gap between incompatible interfaces.
- Decorator – Dynamically extends the functionality of an object without modifying its code.
- Facade – Provides a simplified interface to a complex subsystem.
These patterns focus on object creation mechanisms to increase flexibility and reuse.
- Factory Method – Provides an interface for creating objects but allows subclasses to alter the type of objects created.
- Singleton – Ensures that a class has only one instance and provides a global point of access to it.
- Builder – Allows the step-by-step creation of complex objects, improving readability and maintainability.
Design Pattern | Documentation |
---|---|
Memento | 📜 README |
State | 📜 README |
Iterator | 📜 README |
Strategy | 📜 README |
Template Method | 📜 README |
Command | 📜 README |
Observer | 📜 README |
Mediator | 📜 README |
Chain Of Responsibility | 📜 README |
Visitor | 📜 README |
Prototype | 📜 README |
Singleton | 📜 README |
Factory Method | 📜 README |
Abstract Factory | 📜 README |
Builder | 📜 README |
Composite | 📜 README |
Adaptor | 📜 README |
Decorator | 📜 README |
Facade | 📜 README |
Fly Weight | 📜 README |
Bridge | 📜 README |
Proxy | 📜 README |
- Memento: Save and restore an object's internal state without violating encapsulation.
- State: Allow an object to alter its behavior when its internal state changes.
- Iterator: Provide sequential access to elements of a collection object without exposing its underlying implementation.
- Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
- Template Method: Define the skeleton of an algorithm in a method, and let subclasses provide specific implementations for certain steps.
- Command: Encapsulate a request as an object, thereby letting you parameterize clients with queues, requests, and operations.
- Observer: Establish a one-to-many notification mechanism between objects, so that when one object changes state, all its dependents are notified automatically.
- Mediator: Define an object that encapsulates how a set of objects interact, reducing direct dependencies between them.
- Chain Of Responsibility: Avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request.
- Visitor: Separate an algorithm from the object structure on which it operates, allowing addition of new operations to object structures without modifying the classes.
- Prototype: Create new objects by copying an existing prototype.
- Singleton: Ensure a class has only one instance and provide a global point of access to it.
- Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate.
- Abstract Factory: Provide an interface for creating families of related objects without specifying their concrete classes.
- Builder: Separate the construction of a complex object from its representation so that the same construction process can create different representations.
- Composite: Compose objects into tree structures to represent part-whole hierarchies.
- Adaptor: Convert the interface of a class into another interface clients expect, letting classes with incompatible interfaces work together.
- Decorator: Attach additional responsibilities to an object dynamically.
- Facade: Provide a unified interface to a set of interfaces in a subsystem.
- Flyweight: Use sharing to support efficient fine-grained objects.
- Bridge: Decouple an abstraction from its implementation, allowing the two to vary independently.
- Proxy: Provide a surrogate or placeholder for another object to control access to it.