#dependency inversion

Dependency Inversion Principle Tutorial with Java Code Example for Students

 https://youtu.be/_v7JVQsRkN4

Hello friends, new #video on #dependencyinversion #solidprinciples with #Java #coding #example is published on #codeonedigest #youtube channel. Learn #dip #dependency #inversion #principle #programming #coding with codeonedigest.

https://youtu.be/_v7JVQsRkN4 Hello friends, new #video on #dependencyinversion #solidprinciples with #Java #coding #example is published on #codeonedigest #youtube channel. Learn #dip #dependency #inversion #principle #programming #coding with codeonedi

 Dependency Inversion Principle is the fifth and final Solid principle. Robert C. Martin’s definition of the Dependency Inversion Principle consists of two parts. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. An important detail to note here is that high-level and…

The books Agile Software Development, Principles, Patterns, and Practices and Agile Principles, Patterns, and Practices in C# are the best resources for fully understanding the original goals and motivations behind the Dependency Inversion Principle. The article "The Dependency Inversion Principle" is also a good resource, but due to the fact that it is a condensed version of a draft which eventually made its way into the previously mentioned books, it leaves out some important discussion on the concept of a package and interface ownership which are key to distinguishing this principle from the more general advise to "program to an interface, not an implementation" found within the book Design Patterns (Gamma, et. al).

To provide a summary, the Dependency Inversion Principle is primarily about reversing the conventional direction of dependencies from "higher level" components to "lower level" components such that "lower level" components are dependent upon the interfaces owned by the "higher level" components. (Note: "higher level" component here refers to the component requiring external dependencies/services, not necessarily its conceptual position within a layered architecture.) In doing so, coupling isn't reduced so much as it is shifted from components that are theoretically less valuable for reuse to components which are theoretically more valuable for reuse.

This is achieved by designing components whose external dependencies are expressed in terms of an interface for which an implementation must be provided by the consumer of the component. In other words, the defined interfaces express what is needed by the component, not how you use the component (e.g. "INeedSomething", not "IDoSomething").

What the Dependency Inversion Principle does not refer to is the simple practice of abstracting dependencies through the use of interfaces (e.g. MyService → [ILogger ⇐ Logger]). While this decouples a component from the specific implementation detail of the dependency, it does not invert the relationship between the consumer and dependency (e.g. [MyService → IMyServiceLogger] ⇐ Logger.

The importance of the Dependency Inversion Principle is seen primarily in the development of reusable software components which rely upon external dependencies (logging, validation, etc.) since taking dependencies upon such dependencies requires your consumers to require the same dependencies as well. This can be problematic when consumers of your library choose to use a different library for the same infrastructure needs (e.g. NLog vs. log4net), or if they choose to use a later version of the required library which isn't backward compatible with the version required by your library.

A longer discussion of this principle as it relates to the simple use of interfaces, Dependency Injection, and the Separated Interface pattern can be found 

here

.

It basically says:

High level modules should not depend upon low-level modules. Both should depend upon abstractions.

Abstractions should never depend upon details. Details should depend upon abstractions.

As to why it is important, in short: changes are risky, and by depending on a concept instead of on an implementation, you reduce the need for change at call sites.

Effectively, the DIP reduces coupling between different pieces of code. The idea is that although there are many ways of implementing, say, a logging facility, the way you would use it should be relatively stable in time. If you can extract an interface that represents the concept of logging, this interface should be much more stable in time than its implementation, and call sites should be much less affected by changes you could make while maintaining or extending that logging mechanism.

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependencyrelationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e., reversed), thus rendering high-level modules independent of the low-level module implementation details. The principle states:[1]

A. High-level modules should not depend on low-level modules. Both should depend onabstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

Important Edit: This previous post was on Monads, but I did not understand the full meaning of them. Specifically, I missed the chainability part. So I removed that and just kept the dependency inversion content.

It is best to just explain this with an example. Without using dependency inversion:

var getCells = function(width) { return width * width; }; var makeCellSentence = function(name, width) { return 'A ' + name + ' has ' + getCells(width) + ' cells'; }; console.log(makeCellSentence('2D Matrix', 5)); // A 2D Matrix has 25 cells

This is fine as long as getCells never changes, but if it changes name for example, then you have to modify the original function. To avoid this just place the dependencies of getting the cell number in the getCells callback:

var makeCellSentence = function(name, getCells) { return 'A ' + name + ' has ' + getCells() + ' cells'; }; console.log(makeCellSentence('2D Matrix', function() { return getCells(5); })); // A 2D Matrix has 25 cells

Then later if the name of getCells changes to getCells2. The makeCellSentence function can remain unmodified:

console.log(makeCellSentence('3D Matrix', function() { return getCells2(5); })); // A 3D Matrix has 25 cells

This process is called dependency inversion because you are inverting the dependency of the getCells call with an argument to a higher level. The ideal (and usually not achieved) being only your top level knows about your dependencies, so you only need to update one location when somethings needs to be switched out.

Bir yazılımı tasarlarken kabaca low-level sınıflar (disk erişimi, network protokolleri) ve high-level sınıflar (iş akışları) gibi ayırdığımızı varsayalım. Bu tip yapılarda mantık olarak high-level sınıfların yaptıkları işlerde low-level sınıflara bağımlı olarak tasarlanması gerektiğini düşünebiliriz. Ama bu yapı aslında hiçde işlevsel olmayan bir yapı. Ya low-level sınıflardan birini değiştirirsek ne olur? Karışık olduğunu varsaydığımız high-level sınıfda bir sürü değişiklik yapmak gerekebilir, unit testleri tekrardan uygulamak gerekebilir ki bunu istemeyiz.

Bu tip sorunları ortadan kaldırmak için high-level sınıflar ile low-level sınıflar arasına abstract bir katman atmak gerekir. High-level sınıflar ne kadar karmaşık olursa olsun low-level sınıflardan habersiz çalışabilmeli, abstract katman ise low-level sınıflardan bağımsız tasarlanmalı. Low-level sınıflar ise abstract katmana göre oluşturulmalı. Kısaca şekillendirmek gerekirse

High Level Sınıflar -> Abstract Katman -> Low Level Sınıflar

Örnek

Aşağıdaki örnek Dependency Inversion Prensibine aykırı olarak tasarlanmış. "Manager" sınıfı high-level bir sınıf ve "Worker" ise low-level bir sınıf. Bir zaman sonra, şirketimizde farklı bir çalışan tipini eklememiz gerekti ve bunun içinde yapıya "SuperWorker" sınıfını eklemek zorunda kaldık. Varsayın ki "Manager" sınıfı oldukça karışık. Böyle bir durumla karşılaştığımızda, tahmin edebilirsiniz ki "SuperWorker" sınıfını da işin içine dahil edebilmek için "Manager" sınıfında oldukça fazla değişiklik yapmak gerekebilir. Bunu yaparken kodu bozmanız yüksek olasılık. E tabi bi de Unit Testlerin baştan çalıştırılması durumu var.

// Dependency Inversion Principle - Bad example class Worker { public void work() { // ....working } } class Manager { Worker worker; public void setWorker(Worker w) { worker = w; } public void manage() { worker.work(); } } class SuperWorker { public void work() { //.... working much more } }

Yapı eğer Dependency Inversion Prensibine göre tasarlanmış olsaydı böyle bir sorunumuz olmayacaktı. Yapıyı, "Manager" sınıfı, IWorker interface'i ve bu interface'i implemente eden Worker sınıfı olarak tasarlasaydık eğer "SuperWorker" sınıfını eklerken tek yapmamız gereken bu sınıfa IWorker interface'ini implemente etmek olacaktı. Aşağıdaki örnek Dependecy Inversion Prensibine sadık kalarak yazılmış.

// Dependency Inversion Principle - Good example interface IWorker { public void work(); } class Worker implements IWorker{ public void work() { // ....working } } class SuperWorker implements IWorker{ public void work() { //.... working much more } } class Manager { IWorker worker; public void setWorker(IWorker w) { worker = w; } public void manage() { worker.work(); } }

Kod'a bakınca görüyoruz ki "Manager" sınıfı artık sadece IWorker'ı bilmekte. "Worker" ve "SuperWorker" IWorker'ı implemente ettiği için high-level sınıflarda ek değişiklik yapmaya gerek kalmadı. Unit Testlerimiz taş gibi olduğu yerde duruyor.

Sonuç Dependency Inversion Prensibine bağlı çalışırken, high-level sınıflar abstract katman olarak Interface'leri kullanır ve takdir edersiniz ki kodunuzun içinde "new" operatörünü kullanarak low-level bir sınıfı oluşturamazsınız. Bunu aşmak içinde bazı Creational Design Pattern'ları (Factory Method, Abstact Factory, Prototype) kullanmak gerekebilir.

Bu prensibi kullanmanın neticesi ise fazla efor sarfetmektir. Arada kullandığınız abstract katman yüzünden bir sürü Interface ile uğraşmak zorundasınız ve buda işleri biraz karıştırır. Tabii ki karşılığında esnek bir kod yapısına sahip olursunuz. Bu prensibi öyle gelişi güzel heryerde kullanmamak gerekir. Eğer değişmeyecek bir kod yapınız varsa bu prensibi kullanmak oldukça yersiz olur.