10. Systems - tuansondinh/clean_code GitHub Wiki
10.1 How would you build a city?
Cities work because:
- "...cities have teams of people who manage particular parts of the city..." (water, power etc.) S.154
- they evolved from appropriate complexity/abstraction and modularity
- Clean Code -> organize at lower levels of abstraction
- How to stay clean in high level abstraction / system level?
10.2 Separate Constructing a System from Using it
- construction is different process from use
- "The separation of concerns is one of the oldest and most important design techniques in our craft." S.154
BAD - Lazy Initialization/Evaluation - mixing up startup and runtime logic:
- good: constructs object when really needed; faster startup; null is never returned
- bad: hard-coded dependency on
MyServiceImpl
-> can't compile without resolving these dependencies
public Service getService() {
if (service == null)
service = new MyServiceImpl(...); // Good enough default for most cases? return service;
}
"...we should make sure that we have a global, consistent strategy for resolving our major dependencies." S.155
10.3 Separation of Main (S.155)
- "move all aspects of construction to
main
, or modules called bymain
..." - "...design the rest of the system assuming that all objects have been constructed and wired up appropriately.
- "The main function builds the objects necessary for the system, then passes them to the application, which simply uses them."
- "...the application has no knowledge of main or of the construction process."
10.4 Factories
- application can say when an object gets created -> use ABSTRACT FACTORY pattern
- construction is still seperate from app code
10.5 Dependency Injection
- powerful method to separate construction from use
- use of _Inversion of Control _ to dependency management
- IoC "...moves secondary responsibilities from an object to other objects, that are dedicated to the purpose" (S.157) -> supports SRP
- an object should not be responsible for instantiating dependencies -> should pass it too other mechanism -> inverting control
WIP
10.6 Scaling Up
- start small with low complexity, then expand -> iterative and incremental agility "Test-driven development, refactoring, and the clean code they produce make this work at the code level." S.158
On System Level: "Their architectures can grow incrementally, if we maintain the proper separation of concerns." S.158 WIP