- Single responsibility principle:
- there should never be more than one reason for a class to change
- Open closed principle:
- a module should be open for extension and closed for modification
- Liskov substitution principle:
- subclasses should be substitutable for their base classes
- Interface segregation principle:
- many client specific interfaces are better than one general purpose interface
- Dependency inversion principle:
- Depend upon abstractions, not concretions
Questions to ask about a piece of code (mentioned in Sandi Metz’ SOLID Design talk.)
- Is it DRY?
- Does it have one responsibility?
- Does everything in it change at the same rate?
- Does it depend on things that change less often that it does?
Some ideas on tests from Sandi Metz’ SOLID Design talk:
- Only mock classes you own
- Don’t mock/stub object under test
- If tests are hard to write, it indicates a problem with design
- TDD will punish you if you don’t understand design
Desirable characteristics of object-oriented code, described in Growing Object Oriented Software, Guided by Tests, a book by Steve Freeman and Nat Pryce:
- Loosely coupled
- Highly cohesive
- Easily composable
- Context independent
Symptoms of rotting design
(Described in Roebrt Martin’s paper, Design Principles and Design Patterns)
- Rigidity: tendency for software to be difficult to change, even in simple ways
- Fragility: tendency of the software to break in many places every time it is changed
- Immobility: inability to reuse software from other projects or from parts of the same project
- Viscosity of design: design preserving methods are harder to employ than hacks.
- Viscosity of environment: dev environment is slow and inefficient. e.g. slow compile times, long CI cycle.
- Provides vocabulary for communicating intent
- Help build better quality software
This is a programming exercise suggested by Jeff Bay, in the book Thoughtworks Anthology. In it, he suggests following 9 “rules of thumb” that push you towards better object oriented programming.
- One level of indentation per method
- Don’t use
- Wrap all primitives and strings
- First class collections
- One dot per line
- Don’t abbreviate
- Keep all entities small
- No classes with > 2 instance variables
- No getters, setters, properties
- The Principles of OOD on Robert C Martin’s blog.