- 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
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
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
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
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
- Your classes should be small. No more than a screen full of
- Avoid ‘god’ classes.
- Split big classes into smaller classes.