{"componentChunkName":"component---src-templates-blog-post-js","path":"/Depedency-Inversion/","result":{"data":{"site":{"siteMetadata":{"title":"Ibrahim personal blog","author":"Ibrahim"}},"markdownRemark":{"id":"d0760818-ca0b-5cbd-870c-417fe96fde36","html":"

Here we go πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€πŸš€\nImagine what software development was like before a safe and convenient mechanism for polymorphism was available, it was manually handled via pointers in C and other old languages.

\n

Dependency Inversion

\n

In the typical calling tree, main functions called high-level functions, which called mid-level functions, which called low-level functions. In that calling tree, however, source code dependencies inexorably followed the flow of control.

\n

Sounds interesting?

\n
But let’s take a look at how the process flows
\n

Let’s say that the main function calls out high-level function,\nthe middle-level function acts as an interface for F(), however, that the source code dependency (the inheritance relationship)\nbetween ML1 and the interface, I point in the opposite direction compared to the flow of control.

\n

The fact that OO languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted.

\n

With this approach:nerd_face:, architects who working in systems written in OO languages have absolute control over the direction of all source code dependencies flow in the system. They are not constrained to align those dependencies with the flow of control they can add more dependencies as a sort of plugin thanks to polymorphism:heart:.

\n

Also this principle makes your program functionality clear and agile.

\n

No matter which module does the calling and which module is called, the software architect can point the source code dependency in either direction.

\n
That is power! That is the power that OO provides. That’s what OO is really.
\n

All about at least from the architect’s point of view.\nWhat 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.

\n

This means that the UI is the main function, the database and business logic can be plugins to the system’s rules. It means that the source code of the business rules never mentions the UI or the database.\nAnd this will help in software fast delivery.\nFor further check out the book of architecture called clean architecture by Robert-C,-Martin.

","timeToRead":2,"frontmatter":{"title":"What is depedency inversion","date":"July 05, 2019","spoiler":null,"tags":null},"fields":{"slug":"/Depedency-Inversion/","langKey":"en"}}},"pageContext":{"slug":"/Depedency-Inversion/","previous":{"fields":{"slug":"/Single-responsibilty/","langKey":"en","directoryName":"Single-responsibilty","maybeAbsoluteLinks":[]},"frontmatter":{"title":"the SRP principle"}},"next":{"fields":{"slug":"/SOLID-Principles/","langKey":"en","directoryName":"SOLID-Principles","maybeAbsoluteLinks":[]},"frontmatter":{"title":"The \"SOLID\" Principles in designing software"}},"translations":[],"translatedLinks":[]}}}