I am reading Clean Architecture by Robert Martin, chapter 5. It says (the quote is not 100% accurate, I changed it for brevity):
In Figure above, module HL1 calls the F() function in module ML1 . The fact that it calls this function through an interface is a source code contrivance. At runtime, the interface doesn’t exist. HL1 simply calls F() within ML1 .
Note, however, that the source code dependency (the inheritance relationship) between ML1 and the interface I points in the opposite direction compared to the flow of control. This is called dependency inversion.
Now look back at that calling tree in Figure above , and its many source code dependencies. Any of those source code dependencies can be turned around by inserting an interface between them.
With this approach, software architects working in systems written in OO languages have absolute control over the direction of all source code dependencies in the system. They are not constrained to align those dependencies with the flow of control. No matter which module does the calling and which module is called, the software architect can point the source code dependency in either direction.
That is power! That is the power that OO provides. That’s what OO is really all about—at least from the architect’s point of view. What can you do with that power? As an example, you can rearrange the source code dependencies of your system so that the database and the user interface (UI) depend on the business rules, rather than the other way around.
This means that the UI and the database can be plugins to the business rules. It means that the source code of the business rules never mentions the UI or the database.
As a consequence, the business rules, the UI, and the database can be compiled into three separate components or deployment units (e.g., jar files, DLLs, or Gem files) that have the same dependencies as the source code. The component containing the business rules will not depend on the components containing the UI and database.
In turn, the business rules can be deployed independently of the UI and the database. Changes to the UI or the database need not have any effect on the business rules. Those components can be deployed separately and independently.
In short, when the source code in a component changes, only that component needs to be redeployed. This is independent deployability.
If the modules in your system can be deployed independently, then they can be developed independently by different teams. That’s independent developability.
OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies.
I understand that we can control the flow by for example, if-else, loops etc. What I do not understand is:
- How does an interface change the control flow?
- What did he mean by "At runtime, the interface doesn’t exist"?
- What did he mean by "source code dependency (the inheritance relationship) between ML1 and the interface I points in the opposite direction"?
- How an interface can invert the dependency?
- How by using an interface the database and the user interface (UI) depend on the business rules?
- How by using an interface source code of the business rules never mentions the UI or the database?
- Then how does the business rules use the UI or the database (without mentioning them)?
- If the component containing the business rules will not depend on the components containing the UI and database, then how will we use the CRUD operations or show the output?
