- Abstractions should not depend upon details
- Details should not depend upon abstractions
- Important that higher level and lower level objects depend on the same abstract interaction
- This is not the same as Dependency Injection – which is how objects obtain dependent objects
Tag: SOLID
Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they do not use.
- Make fine grained interfaces that are client specific
- Many client specific interfaces are better than one “general purpose” interface
- Keep your components focused and minimize dependencies between them
- Notice relationship to the Single Responsibility Principle?
- avoid ‘god’ interfaces
Liskov Subsitution Principle
If it looks like a duck and quacks like a duck but it needs batteries, you probably have the wrong abstraction.
- By Barbara Liskov, in 1998
- Objects in a program would be replaceable with instances of their subtypes WITHOUT altering the correctness of the program.
- Violations will often fail the “Is a” test.
- A Square “Is a” Rectangle
- However, a Rectangle “Is Not” a Square
Open/Closed Principle
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
- Your classes should be open for extension
- But closed for modification
- You should be able to extend a classes behavior, without modifying it.
- Use private variables with getters and setters – ONLY when you need them.
- Use abstract base classes
Single Responsibility Principle
Just because you can doesn’t mean you should.
- A class should have only one reason to change.
- There should never be more than one reason for a class to
change. - Your classes should be small. No more than a screen full of
code. - Avoid ‘god’ classes.
- Split big classes into smaller classes.