{"id":61,"date":"2011-09-19T14:16:43","date_gmt":"2011-09-19T14:16:43","guid":{"rendered":"http:\/\/www.lexicalscope.com\/blog\/?p=61"},"modified":"2011-09-19T14:40:07","modified_gmt":"2011-09-19T14:40:07","slug":"dependency-inversion","status":"publish","type":"post","link":"https:\/\/www.lexicalscope.com\/blog\/2011\/09\/19\/dependency-inversion\/","title":{"rendered":"Dependency Inversion"},"content":{"rendered":"

What is a Dependency<\/h3>\n

For the purposes of this discussion a class A<\/code> has a dependency on another class B<\/code>, iff you cannot compile class A<\/code> without class B<\/code>.<\/p>\n

Example<\/p>\n

\r\nclass A \u000b{\u000bB b;\u000b}\u000b\u000b\r\nclass B\u000b { \u000b}\r\n<\/pre>\n
\"Box<\/a><\/p>\n
We have to compile class B<\/code> before (or at the same time as) class A<\/code>.<\/strong><\/p>\n
Other kinds of Dependency<\/h3>\n
Anywhere the name “B<\/code>” appears in class A<\/code> creates a dependency. Some other examples of dependencies are:<\/p>\n
\r\nclass A extends B \u000b{ \u000b}\r\nclass A implements B\u000b { \u000b}\r\n\u000b\u000bclass A \u000b{\u000b void method(B b) { } \u000b}\r\n<\/pre>\n
Transitive Dependencies<\/h3>\n
If a class A<\/code> depends on another class B<\/code> which itself has dependencies then the dependencies of class B<\/code> are effectively dependencies of class A<\/code><\/p>\n
Example:<\/p>\n
\r\nclass A\u000b { B b;\u000b }\r\n\u000b\u000bclass B \u000b{ C c;\u000b } \u000b\r\nclass C \u000b{\u000b \u000b}\r\n<\/pre>\n
\"Box<\/a><\/p>\n
We have to compile class C<\/code> before (or at the same time as) class B<\/code> and class A<\/code>.<\/strong><\/p>\n
The Problem<\/h3>\n
When class C<\/code> changes, we have to recompile and retest both class A<\/code> and class B<\/code>. In a large system this can take a very long time. It also means that you have to know about class C<\/code> in advance; you cannot decide on class C<\/code> after deciding on class A<\/code>.<\/p>\n
If class C<\/code> is a more concrete class then it might change more frequently than class A<\/code>. This will cause class A<\/code> to be recompiled\/tested much more frequently than it otherwise would need to be.<\/p>\n
The Solution<\/h3>\n
Inverting Dependencies<\/h4>\n
Have class A<\/code> and class B<\/code> both depend on an abstraction I<\/code>. This inverts the direction of the dependency arrow on class B<\/code>.<\/p>\n
\r\ninterface I { \u000b}\r\nclass A \u000b{ I i; \u000b}\r\nclass B implements I \u000b{ \u000b}\r\n<\/pre>\n
\"Box<\/a><\/p>\n
Breaks Transitive Dependency<\/h4>\n
The really helpful effect of this inversion is that it also breaks the transitive dependency from class A<\/code> onto class B<\/code><\/p>\n
\r\ninterface I\u000b{\u000b }\r\nclass A \u000b{\u000b I i;\u000b }\r\nc\u000blass B implements I\u000b{ C c; \u000b}\r\nc\u000blass C\u000b { \u000b}\r\n<\/pre>\n
\"Box<\/a><\/p>\n
Dependency Inversion Principle<\/h3>\n
This is an application of the Dependency Inversion Principle<\/a>:<\/p>\n