This is an old revision of the document!
Clean Code notes
Single responsibility principle
- responsibility
- It is about users
- People served by a responsibility will request changes
- Set of functions that serve a particular actor
- The actor is the single source of change for the functions in a responsibility
- Primary and secondary value of software
- Primary: can be changed easily, so that it can continue to meet changing needs of customer
- Secondary: meets current needs of current customer
- Primary value is achieved in the process of assigning functions to modules
- Mixing responsibilities in one module reduces primary value of the software
- Fan out
- Multiple responsibilities result in a fan out of dependencies
- Minimize fan out by minimizing responsibilities
- Colocation of responsibilities couples actors
- change in one responsibility requires recompile of actors using other responsibilities
- SRP: module should have one and only one reason to change
- Examples
- logging
- separate log statements into subclass
- extract till you drop to make logging granularity eork
- subclass logs around super calls
- Solutions
- Extract classes
- Move responsibilities and impls into separate classes
- Facade
- Unify responsibility impls in one facade
- Interface segregation
- Create one interface per responsibility
- Implement in single class
- No perfect solution
- Keep responsibilities separate/makes stuff more difficult to find
- Put responsibilities together/makes stuff easier to find/work with
- Mastermind
- Actors
- Designer: responsible for game messages
- Strategist: algorithm that guesses the code
- Customer: how game progresses, badges, achievements, etc.
- Modules
- gameplay: supports customer
- strategy: supports strategist
- interface: supports sesifner
- see mastermind example