{"id":1701,"date":"2021-03-06T14:04:50","date_gmt":"2021-03-06T13:04:50","guid":{"rendered":"http:\/\/mateuszglowinski.pl\/?p=1701"},"modified":"2021-03-06T16:01:39","modified_gmt":"2021-03-06T15:01:39","slug":"dependency-inversion-principle","status":"publish","type":"post","link":"https:\/\/mateuszglowinski.pl\/index.php\/2021\/03\/06\/dependency-inversion-principle\/","title":{"rendered":"Dependency Inversion Principle"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What is „Dependency Inversion Principle” (DIP) ?<\/h4>

It is the fifth<\/span><\/span> rule of the SOLID design rules (it stands for D in SOLID acronym).<\/span><\/span><\/p>

Definition<\/h4>

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details.<\/p>

Robert C. Martin (Uncle Bob)<\/div><\/div><\/blockquote>

In simpler words<\/span><\/span>, <\/span><\/span>dependencies should depend on abstraction as much as possible and not on a specific type.<\/span><\/span><\/p>

Real-life example<\/h4>

Let\u2019s say we have an vet application that check health of animals.<\/p>

public class Launcher {\n    public static void main(String[] args) {\n        Vet vet = new Vet();\n        vet.checkHealth(AnimalType.dog);\n        vet.checkHealth(AnimalType.cat);\n    }\n}\n<\/pre>
public enum AnimalType {\n\n    dog,\n    cat\n}\n<\/pre>
public class Dog {\n\n    public void checkHealth() {\n\n        System.out.println(\"Checking dog health\");\n    }\n}\n<\/pre>
public class Cat {\n\n    public void checkHealth() {\n\n        System.out.println(\"Checking cat health\");\n    }\n}\n<\/pre>
public class Vet {\n\n    private final Dog dog;\n    private final Cat cat;\n\n    public Vet() {\n\n        this.dog = new Dog();\n        this.cat = new Cat();\n    }\n\n    public void checkHealth(AnimalType animalType) {\n\n        switch (animalType) {\n\n            case dog:\n                this.dog.checkHealth();\n                break;\n            case cat:\n                this.cat.checkHealth();\n                break;\n            default:\n                break;\n        }\n    }\n}\n<\/pre>
UML diagram of our application:<\/p>
\"\"<\/p>
The Vet<\/em> class is closely related to the Dog<\/em> and Cat<\/em> classes, it cannot exist without these two classes, due to that out program does not meet the DIP<\/em> rule. <\/span><\/span><\/p>
We can fix it by removing\u00a0composition<\/a> in Vet class.<\/p>
public class Launcher {\n    public static void main(String[] args) {\n\n        Vet vet = new Vet();\n        vet.checkHealth(new Dog());\n        vet.checkHealth(new Cat());\n    }\n}\n<\/pre>
public interface Animal {\n    void checkHealth();\n}\n<\/pre>
public class Dog implements Animal {\n\n    public void checkHealth() {\n\n        System.out.println(\"Checking dog health\");\n    }\n}\n<\/pre>
public class Cat implements Animal {\n\n    public void checkHealth() {\n\n        System.out.println(\"Checking cat health\");\n    }\n}\n<\/pre>
public class Vet {\n\n    public void checkHealth(Animal animal) {\n        animal.checkHealth();\n    }\n}\n<\/pre>
Now, Vet<\/em> class can exists without any other class. Moreover checkHealth<\/em> method depends from abstraction, which is in line with the DIP<\/em> rule.
<\/span><\/span><\/p>
UML diagram of our application after refactoring:<\/p>
\"\"<\/p>
Why should I follow „Dependency Inversion Principle” ?<\/h4>
This rule helps to reduce the number of dependencies among modules and thanks to that code is easier to extend and maintain. Moreover classes are not tightly coupled with the lower-level objects and we can easily reuse the logic from the high-level modules.<\/p>
What to look for?<\/h4>
DIP <\/em>is the rule, which is really common while creating libraries\/packages. It is strongly recommended, that such a code does not require an outside composition.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
What is „Dependency Inversion Principle” (DIP) ? It is the fifth rule of the SOLID design rules (it stands for D in SOLID acronym). Definition…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[34],"tags":[35],"_links":{"self":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1701"}],"collection":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1701"}],"version-history":[{"count":61,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1701\/revisions"}],"predecessor-version":[{"id":1793,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1701\/revisions\/1793"}],"wp:attachment":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}