Working Effectively with Legacy Code chap 7 - It takes Forever to make a change - Understanding, Lag Time and Dependencies
Breaking dependencies
Build Dependencies
aha The Dependency Inversion Principle
Now we have a package, OpportunityProcessing, that really has no dependencies on the database implementation. Whatever tests we write and place in the package should compile quickly, and the package itself doesn’t have to recompile when we change code in the database implementation classes.
The Dependency Inversion Principle
When your code depends on an interface, that dependency is usually very minor and unobtrusive. Your code doesn’t have to change unless the interface changes, and interfaces typically change far less often than the code behind them. When you have an interface, you can edit classes that implement that interface or add new classes that implement the interface, all without impacting code that uses the interface.
For this reason, it is better to depend on interfaces or abstract classes than it is to depend on concrete classes. When you depend on less volatile things, you minimize the chance that particular changes will trigger massive recompilation.
When you introduce more interfaces and packages into your design to break dependencies, the amount of time it takes to rebuild the entire system goes up slightly. There are more files to compile. But the average time for a make, a build based on what needs to be recompiled, can go down dramatically.
When you start to optimize your average build time, you end up with areas of code that are very easy to work with. It might be a bit of a pain to get a small set of classes compiling separately and under test, but the important thing to remember is that you have to do it only once for that set of classes; afterward, you get to reap the benefits forever.
Summary
The techniques I’ve shown in this chapter can be used to speed up build time for small clusters of classes, but this is only a small portion of what you can do using interfaces and packages to manage dependencies. Robert C. Martin’s book Agile Software Development: Principles, Patterns, and Practices (Pearson Education, 2002) presents more techniques along these lines that every software developer should know.
This approach to structuring the Opportunity Processing package sounds efficient! It reminds me of how I felt when I used a do my online economics class service to streamline my studies. Focusing on what matters without unnecessary dependencies makes a huge difference!
ReplyDelete