Skip to main content

guidelines for object-oriented design

  1. SOLID Principles:

    • Single Responsibility Principle (SRP): A class should have only one reason to change.
    • Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
    • Liskov Substitution Principle (LSP): Subtypes should 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, and abstractions should not depend on details.
  2. DRY (Don't Repeat Yourself): Avoid duplication of code by abstracting common functionalities into reusable components or functions. This principle emphasizes the importance of modularity and maintainability.

  3. KISS (Keep It Simple, Stupid): Strive for simplicity in design and implementation. Complex solutions should be avoided in favor of simpler, more straightforward ones whenever possible.

  4. YAGNI (You Aren't Gonna Need It): Avoid adding unnecessary features or functionality to the software based on speculation about future needs. Only implement features that are necessary based on current requirements.

  5. Separation of Concerns (SoC): Divide the software into distinct sections, with each section addressing a separate concern or responsibility. This principle promotes modularity, maintainability, and reusability.

  6. Composition Over Inheritance: Prefer composition (building objects by assembling smaller, reusable components) over inheritance (creating new classes by extending existing ones). This approach leads to more flexible and maintainable code.

  7. Fail-Fast Principle: Identify and report errors as soon as they occur, rather than allowing them to propagate and potentially cause more significant issues later on. This principle helps in diagnosing and fixing problems quickly.

  8. Law of Demeter (LoD): Also known as the principle of least knowledge, this principle states that a module should have limited knowledge about other modules. It promotes loose coupling between components, which enhances maintainability and flexibility.

  9. Single Source of Truth (SSOT): Store each piece of information in the system in a single, authoritative location. This ensures consistency and reduces the risk of data inconsistencies.

  10. Testing Principles:

    • Test-Driven Development (TDD): Write tests before writing code to ensure that the code meets the requirements.
    • Unit Testing: Test individual units (e.g., functions, methods, or classes) of code in isolation to ensure they behave as expected.
    • Integration Testing: Test the interactions between different units or modules to ensure they work together correctly.
    • Continuous Integration (CI) and Continuous Deployment (CD): Automate the process of building, testing, and deploying software to ensure that changes are integrated and deployed smoothly.