This episode talks about the Dependency Inversion principle.
- Dependency Inversion Begins
- Independent Deployability
- What is dependency
- Run Time Dependency exist whenever two module interact at run time.
- Compile Time (Source Code) Dependency exist when a name is define in one module but use in another module.
- If Module A uses the name from Module B, then you can’t compile Class A only, you must also compile both A and B because Class A depends on Class B.
- Structured Design
- A top-down methodology by start with main and design what main should call and so on down the tree.
- The source code dependency follows the same path as the run time dependency.
- Dependency Inversion
- The purpose is to have source code dependency going the opposite of the run time dependency path.
- The solution is polymorphism.
- A –> B [+f()], if A call f() in B, then A has both run-time and source-code dependency on B.
- A–> Interface[+f()] <– B [+f()], insert an interface between A and B by having A uses the Interface while B implement it. Then A has run-time dependency on the Interface but not compile time dependency. And B has source-code dependency on the Interface.
- Dependency Inversion create a boundary for the software. We want all the dependency across the boundary are pointing to the same direction, the application.
- This is by creating plugin that depend on the application.
- Architectural Implications
- High level policy should not depend on low level details
- Low level details should depend on high level policy.
- High level like use cases.
- Low level like web pages and database.
- Therefore, design the low level details as plugin to the application.
- A Reusable Framework
- Building the reusable framework should be done parallel between those application that uses it.
- The Inversion
- Independent Developability
- Developers can work separately without interfere each other’s module.
- Dependence Inversion Example
- The Furnace Example