Component coupling
Focused on relationships between components
Acyclic dependencies principle
The "morning after syndrome": someone changed something you depend on last night and now your code's broken. Everyone keeps changing their code to fix it which breaks the code depending on them.
It can go on for weeks in large projects.
The weekly build
Used to be common in medium-sized projects. All the developers ignore each other's changes for the first 4 days of the week and then integrate everything on Friday. Can make progress without worrying about it breaking for 4/5 days, but at the cost of having it fix it all on Friday.
On larger projects it becomes less feasible to do the entire integration on Friday, which spills into Saturday. So it gets pushed back to Thursday, and then even further back. Eventually becomes a biweekly build.
The integration time grows with project size, which makes it harder to integrate and test.
Eliminating dependency cycles
Partition the development environment into releasable components. Components become units of work that can be assigned to a developer or team. When a component is ready it is given a release number and moved to another directory. Other teams can decide whether to upgrade the component or not. Each team is independent and do not have an immediate effect on other teams. Integration happens in small increments.
Does not work with cycles.
The dependency structure of the components needs to be managed.
To see who is affected by a release follow the arrows backwards. Those developers need to decide when to integrate.
When a team decides to test their component they just use the version of the dependencies they are currently using. When it's time to do a new release just compile, test, release from bottom up.
The effect of a cycle
The cycle effectively creates one large component which causes the "morning after syndrome". Cycles make it difficult to isolate components, unit testing and releasing become difficult.
With cycles, it can be difficult to work out the order you must build components, there may not be a correct order.
Breaking the cycle
It's always possible to break a cycle. There are two main methods.
- Put an interface in Entities and inherit it into Authorizer, inverting the arrow breaks the cycle.
- Move classes they both depend on to a new component
Jitters
Option 2 creates a new component which implies the component structure can change with new requirements. The dependency structure jitters and grows, and must be monitored for new cycles.