PV168

SOLID

SOLID

• Single Responsibility Principle
• Open Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Introduced by Robert C. Martin (Uncle Bob)

Benefits of using SOLID

• The code becomes easier to understand, manage, maintain, and change
• As our applications grow in size, we can reduce their complexity
• Code becomes more testable

Single Responsibility Principle

Single Responsibility Principle

• Do One Thing and Do It Well
  • Class should do one thing, and that it should also do it well
• The class should always have only one reason to change
• Helps us with:
  • Testing - has fewer test cases
  • Lower Coupling - class with only one responsibility has fewer dependencies
  • Organization - is easier to search that monolithic classes

Open Closed Principle

Open Closed Principle

• Class should be open for extension but closed for modification
• You should be able to extend a classes behavior, without modifying it
• Helps us with:
  • Code in general - class becomes robust, flexible, and reusable
  • Stability - as no modifications are made to the code no bugs can be introduced

Liskov Substitution Principle

Liskov Substitution Principle

• Objects of a superclass should be replaceable with objects of its subclasses without breaking the application
• If class A is a subtype of class B, we should be able to replace B with A without disrupting the behavior of our program
• Helps us with:
  • Design - helps us model good inheritance hierarchies
  • Bug prevention - prevent our old codebase from breaking due to new code

Interface Segregation Principle

Interface Segregation Principle

• Don’t depend on methods you don’t use
• Larger interfaces should be split into smaller ones. By doing so, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them.
• Helps us with:
  • Readability - small interfaces are more readable
  • Reusability - small interfaces are easier to implement and reuse

Dependency Inversion Principle

Dependency Inversion Principle

• High level modules should not depend upon low level modules. Both should depend upon abstractions
• Abstractions should not depend on details. Details should depend on abstractions.
• Rapid Development and Deployment
• Helps us with:
  • Reusability - high-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules
  • Lower Coupling - decouples the high-level and low-level modules from each other