A summary of this week's chapter is pretty simple make sure your code dependencies have no "cycles" which is to say all dependencies should flow in one direction only.
allow no cycles in your component dependency graph
- the author introduces two concepts:
- morning after syndrome: cod you were working on earier doesn't work in future because another developer changed a component elsewhere
- the weekly build: in order to ensure MAS doesn't happen you reduce deployment frequency
- both are listed as problems (with good reason)
- the solution is to partition the development environment into reusable components
- patitioned components must be appropriately versioned so OTHER components can decide when to update their dependency
- changes in partitioned components do not need to have an immediate effect on other teams
- to make this work you must monitor, manage and, maintain the dependency structure over time
- there can be no "cycles" or cirrcular dependencies
- when there are cycles in your dependency graph it can be difficult to figure out what order to build your components in.
- one option is to apply the dependency inversion principle
- another option is to create a new component which both components depend on.
- This dependency flow issue is an ongoing process which requires it be constantly monitored over the lifetime of your project.
- component structure cannot be designed from the top down, insttead it is a system that evolves over time as the system grows and changes
- component structure cannot be planned effectively in advance
- component flow diagras do nothing to describe the FUNCTIONALITY instead they describe the BUILDABILITY and MAINTAINABLILTY of a project
depend in the direction of stability
- designs cannot be static.
- some components must be volotile
- we should plan for volatility by ensuring the more volatile a component is the less likely we are to depend on it
- many factors make a component hard to change
- size
- complexity
- clarity of code
- number of other components that depend on it
- The component in the above diagram may contain only an interface as such it may be referred to as an ABSTRACT compnent.
- the author spends a lot of time discussing making stability measurable
- he presents multiple formulas based on number of dependencies and dependents
- in theory we should calculate stability and work to reduce that by adopting the techniques above (DIP and Shared dependencies).
- not worth digging into the complexity formulas, consider IDE tools may exist which do these calcualtions for us
a component should be as abstract as it is stable
- there is a description of a formula for measuring how abstract a class is
- not particularly useful IMO but for the arguments that follow it is important to believe that you can measure both
- abstractness
- stability
- this part is interesting BUT a lot of work so is unlikely to happen
- the author describes a concept he calls the main sequence
- we have established that we can measure DEPENDENCY and ABSTRACTNESS
- THUS we can also graph those things.
- AND we can place every class' score on a graph of D vs. A
We get something that looks like this
- Useless a class that nothing depends on and has no concrete code (an orphaned interface)
- a pain a class that many things depend on, but is also changing all the time (a database)
- Typically we want classes to live along the main sequence with clusters in the top left and bottom right
- classes can then be further measured in this regard for their distance from the main sequence
- this can help us find areas of concern in our applications
- that final statistic distance from the main sequence can then give us a line graph per component of its COMPLEXITY over time.