Solid Principle Tricks

Applying the SOLID principles can indeed feel overwhelming, especially since the implementation patterns may appear repetitive or hard to differentiate. The key lies in understanding the core intent behind each principle and applying them pragmatically rather than mechanically. Here's a guide to help you consistently adhere to the principles when designing classes in C++:

---

1. Single Responsibility Principle (SRP)

Thumb Rule: Each class should have only one reason to change.

Trick: Use verbs to define class responsibilities. If a class name contains "and" or does too many things, split it.

• ✅ Correct:
  • OrderProcessor processes orders.
  • InvoiceGenerator generates invoices.
• ❌ Wrong:
  • OrderAndInvoiceProcessor both processes orders and generates invoices.

---

2. Open/Closed Principle (OCP)

Thumb Rule: Classes should be open for extension but closed for modification.

Trick: When adding new features, prefer inheritance, interfaces, or polymorphism over modifying existing code. Avoid directly adding logic to old classes.

• ✅ Correct:
  • Add new functionality by creating a subclass or implementing an interface.
  • Use abstract base classes for extensibility.
• ❌ Wrong:
  • Modify existing classes to handle new cases.

Litmus Test: Ask yourself, "Can I add new functionality without touching this class?"

---

3. Liskov Substitution Principle (LSP)

Thumb Rule: Subclasses should be substitutable for their base classes.

Trick: Ensure that overriding methods don’t change the behavior expected from the base class. Use the "is-a" test: If a subclass is not truly a type of its base class, rethink the inheritance.

• ✅ Correct:
  • A Rectangle and Square both override Shape’s getArea().
  • A Bird can fly unless there's a specific reason to separate flightless birds.
• ❌ Wrong:
  • Violating contracts of the base class. Example: A Bird subclass like Penguin that fails to implement the flying behavior expected from Bird.

Litmus Test: Ask, "Can this subclass replace its parent without breaking functionality?"

---

4. Interface Segregation Principle (ISP)

Thumb Rule: Smaller is better. Clients should not depend on interfaces they don’t use.

Trick: Look at the clients of the interface. If different clients need different subsets of methods, split the interface.

• ✅ Correct:
  • Printer, Scanner, and Fax interfaces instead of one Machine interface.
  • Multiple inheritance for interfaces if needed.
• ❌ Wrong:
  • A single monolithic interface (Machine) with print(), scan(), and fax() methods that unrelated clients must implement.

Litmus Test: Ask, "Does this class implement unused methods from an interface?"

---

5. Dependency Inversion Principle (DIP)

Thumb Rule: High-level classes should not depend on low-level classes but on abstractions.

Trick: Always code against interfaces or abstract classes, not concrete implementations. Use dependency injection (constructor injection or setter injection).

• ✅ Correct:
  • Depend on a Logger interface, with FileLogger or ConsoleLogger passed at runtime.
  • Use an abstract Database class with MySQLDatabase or PostgresDatabase as concrete implementations.
• ❌ Wrong:
  • Hardcoding dependencies inside a class (FileLogger logger; instead of Logger* logger;).

Litmus Test: Ask, "Can I easily replace the dependency without modifying this class?"

---

General Guidelines for Ensuring SOLID Principles

1. Start with Abstractions

• When designing a class, ask yourself, "What does this class do?" and "What abstractions or contracts does it need to fulfill?"
• Example: Use abstract base classes or interfaces to define behaviors (Drawable, Logger, Database).

2. Keep Classes Small and Focused

• Each class should represent a single, well-defined concept or functionality. If a class feels too large, break it down into smaller, cohesive components.

3. Avoid Tight Coupling

• Use dependency injection (pass dependencies through constructors or setters).
• Prefer composition over inheritance if it better represents the relationship.

4. Design for Change

• Anticipate potential extensions or changes. Use polymorphism or templates in C++ for behaviors that might change in the future.

5. Test with Real Use Cases

• While designing, imagine how the classes will be used in client code. Adjust the design based on how intuitive and reusable it feels.

---

Practical Thumb Rules

1. Design for Interfaces:

   • Start by designing interfaces (AbstractLogger, Database) and implement concrete classes (FileLogger, PostgresDatabase) later.

2. Favor Composition Over Inheritance:

   • When possible, prefer using member objects (Has-A relationship) rather than subclassing (Is-A relationship). This often naturally adheres to SOLID principles.

3. Review Class Names:

   • A class name should clearly describe its purpose. If it’s vague or contains multiple responsibilities, it’s time to refactor.

4. Use Patterns Smartly:

   • Design patterns like Factory, Adapter, and Dependency Injection naturally enforce SOLID principles when used correctly.

5. Iterative Design:

   • Your first design may not be SOLID. Refactor over time as requirements evolve.

---

Red Flags to Watch Out For

• Fat classes: Classes with many unrelated methods (violates SRP and ISP).
• Concrete dependencies: Classes hardcode specific types instead of using abstractions (violates DIP).
• Rigid inheritance hierarchies: Subclasses break base class contracts (violates LSP).
• Global variables: They lead to tight coupling and are harder to test or replace.
• Hardcoded logic: Makes extending functionality difficult (violates OCP).

---

By keeping these rules and tricks in mind, you'll find it easier to design classes that naturally adhere to the SOLID principles, making your code more maintainable, flexible, and testable.