These guiding principles reduce bugs and increase implementation speed of new features or modifications.
Remember the scope and context of the project. Is it a script? Is it huge? Is it one-off? Is it mission-critical?
You aren't gonna need it/keep it simple stupid tells you when to do something. The other principles tell you how to do something.
SOLID applies to object-orientated programming.
- Single Responsibility Principle
- Think about who - the role - that will be causing what changes and isolate that code together
- Higher cohesion (object has greater focus)
- Lower coupling (object does not connect to or require knowledge of other object)
- Open/Closed Principle
- "An object should be open for extension, but closed for modification"
- This means the design should facilitate new functionality or changes in requirements without modifying existing code
- The object becoming closed means it now has a well-defined interface and may be used by others
- This limits the risk of introducing bugs into already developed & tested code
- In a dynamic language it also means you don't dynamically reach into and modify an object
- Violation smells: switch/if-else statements that can be extended
- Implementation notes: use abstraction and interfaces
- Be aware: Pure inheritance introduces coupling if subclasses depend on implementation details of their parent class.
- When to use: You cannot predict the future so "modifications may be done once, maybe twice, but not thrice before I used OCP"
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Composition over Inheritance
Starting point: https://www.youtube.com/watch?v=3MNVP9-hglc
Inheritance is difficult with Liskov's substitution principle anyway.
Law of Demeter
The principle of least knowledge, in particular for OOD, says to loosely couple the design by having objects only talk to their immediate "friends".