SOLID Design Principles

SOLID Design Principles#

Single-Responsibility Principle#

There should never be more than one reason for a class to change.

  • Reduces complexity of a single class

  • Reduces refactoring

Pragmatics#

  • Break down classes once they’re too big to handle

  • A thing doing an action can have its action being done to the thing.

    @startuml
class Employee {
  + name
  + print_department()
  + print_tax_info()
}
@enduml

    @startuml
class Employee {
  + name
  + print_department()
}
class TaxReport {
  ...
  print(employee: Employee)
}

Employee <- TaxReport
@enduml

Open/Close Principle#

Classes should be open for extension but closed for modification.

  • Reduces risk of breaking a well-tested class when adding new features

Pragmatics#

  • Add a new feature to a class by subclassing the common feature

    @startuml
class Food {
foods: array[tuple[string, float]]
get_calories()
}
note left of Food::get_calories
  for food_name, weight in foods:
    if (food_name == "apple") {return weight * 30}
    else if (food_name == "burger") {return weight * 300 }
    else ...
end note
@enduml

    Adding more types to the above would require modifying the Workout class. Imagine even more methods that requires a check to Workout::type, we would also need to modify those.

    @startuml
Meal o-right-- Food
Food <|-- Apple
Food <|-- Burger

class Meal {
foods: array[Food]
get_calories()
}
note left of Meal::get_calories
  return sum(food.calories() for food in self.foods)
end note

abstract Food {
  {static} calories_per_weight
  weight
  get_calories()
}

class Apple {
}

class Burger {
}

@enduml

Liskov Substitution Principle#

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

Basically, any subclass must be compatible with all methods that takes in its superclass. Specifically this principle has the following rules:

  1. Overridden method types should match or more abstract

  2. Overridden return types should match or be a subtype

  3. Overridden methods exceptions should not throw newer ones

  4. Overridden methods pre-conditions shouldn’t be stronger

  5. Overridden methods post-conditions shouldn’t be weaker

  6. Invariants must be preserved.

  7. Don’t override private fields

Take this motivating example where we the following class design:

@startuml
Rectangle <|-- Square
class Rectangle {
  width
  height
  set_width(val)
  set_height(val)
}
class Square {
  set_width(val)
  set_height(val)
}
note right of Square::set_width
  self.width = self.height = val
end note
note right of Square::set_height
  set_width(val)
end note
@enduml

Say we have a function change_aspect_ratio(rectangle, width, height) that changes the aspect ratio by keep the area of a Rectangle. The issue is this method is not compatible with a Square. This examples violates (6) that mutating the width and height does not affect each other.

Interface Segregation Principle#

Many client-specific interfaces are better than one general-purpose interface

A general-purpose interface can have a lot more methods to be implemented than the concrete class needs causing a lot of unimplemented functions.

Pragmatics#

  • Break down interfaces into many interfaces

    • Break down routes and endpoints

  • This is a double edge sword since more interfaces means more complexity

Dependency Inverstion Principle#

Depend upon abstractions, [not] concretions

Pragmatics#

  • Design and/or implement high-level classes first before low-level classes.

  • Aligns with the direction of test-driven development.

Contents