{"id":659,"date":"2016-05-31T20:18:39","date_gmt":"2016-06-01T04:18:39","guid":{"rendered":"http:\/\/www.timrosenblatt.com\/blog\/?p=659"},"modified":"2016-05-31T20:23:26","modified_gmt":"2016-06-01T04:23:26","slug":"dependency-inversion-principle","status":"publish","type":"post","link":"http:\/\/www.timrosenblatt.com\/blog\/2016\/05\/31\/dependency-inversion-principle\/","title":{"rendered":"Dependency Inversion Principle"},"content":{"rendered":"

Dependency Inversion<\/a> is one of the five SOLID OO principles that’s become so popular in recent years (sometimes referred to as DIP). My opinion is that it’s a highly valuable concept, and is not well-named. “Dependency inversion” doesn’t mean a great deal on its own, and a lot of attempts to explain it tend to get very heady.<\/p>\n

(Speaking of unfortunate naming, “hexagonal architecture” is another concept that I find\u00a0poorly named. Ironic that the concept is about using abstraction to avoid unnecessary coupling, yet the name itself couples the idea to the number 6, which is totally unrelated to the idea. Fortunately, it’s slowly being renamed as “ports and adapters” in most discussions, which is a much better description.)<\/p>\n

My personal preference is towards explanations that are more intuitive, and I’d like to put my two cents in for Dependency Inversion.<\/p>\n

To me, a way of describing Dependency Inversion is to use classes to separate the features of the application (the parts that a user might use) from the technology that makes the feature work<\/em><\/strong>.<\/p>\n

For example, let’s say you have a feature where a user can sign themselves up, and once the user’s information is saved to the database, you have some more steps that need to take place. You could make an interactor<\/a> called<\/p>\n

CompleteUserSetup<\/pre>\n
and it will handle the actions necessary (instead of using a callback).<\/p>\n
Let’s say one of the things it needs to do is send an email welcoming the user.\u00a0Let’s also pretend that you use SendGrid to manage emails. That would mean we\u00a0could<\/strong><\/em> end up with something like<\/p>\n
\r\nclass CompleteUserSetup\r\n  def self.perform\r\n    SendGridClient.email "subjectline", "body of email"\r\n  end\r\nend\r\n\r\nCompleteUserSetup.perform\r\n<\/pre>\n
Will this run? Absolutely. Is it a good example of code that meets the criteria for Dependency Inversion? No.<\/p>\n
What’s happening here is that the feature (user setup) is directly mentioning the technology that implements it (SendGrid). It literally has the name of the tool in the code that is defining the feature.<\/p>\n
\"\"
Literally Rob Lowe<\/figcaption><\/figure>\n
Since there are probably lots of places in the code that send email, if you ever need to switch away from SendGrid, you need to change all those places. Usually it’s not as simple as find-replacing all the instances of “SendGrid” from the code, so a better way is to abstract all of the email interactions into your own class.<\/p>\n
\r\nclass CompleteUserSetup\r\n  def self.perform\r\n    OurEmailClient.send_welcome_email\r\n  end\r\nend\r\n\r\nclass OurEmailClient\r\n  def self.send_welcome_email\r\n    SendGridClient.email "subjectline", "body of email"\r\n  end\r\nend\r\n\r\nCompleteUserSetup.perform\r\n<\/pre>\n
Now the feature doesn’t mention the implementation technology. If you kept this pattern going, “SendGrid” would only ever appear in your email client class, and this means that the technology would be decoupled from the features. This is an Adapter pattern, which is basically the first half of Dependency Inversion. (IMHO this is the most common implementation of DI, and this makes testing really easy)<\/p>\n
To close the loop of “Dependency Inversion” is to actually pass the client an instance of an email client so it can use more than one.<\/p>\n
\r\nclass CompleteUserSetup\r\n  def self.perform(client)\r\n    client.send_welcome_email\r\n  end\r\nend\r\n\r\nclass OurEmailClient\r\n  def send_welcome_email\r\n    SendGridClient.email 'subjectline', 'body of email'\r\n  end\r\nend\r\n\r\nclass OurOtherEmailClient\r\n  def send_welcome_email\r\n    MailChimpClient.email 'subject, 'body of email'\r\n  end\r\nend\r\n\r\nemail_client = OurEmailClient.new\r\nCompleteUserSetup.perform(email_client)\r\n\r\n# or\r\n\r\nemail_client = OurOtherEmailClient.new\r\nCompleteUserSetup.perform(email_client)\r\n<\/pre>\n
Now we’re actually passing the dependency into the location where it’s needed. This means the CompleteUserSetup interactor is totally decoupled from which messaging system it will use.<\/p>\n
The reason this matters is that now we can choose any type of email provider we currently support, and we can also add new types of email providers that we didn’t previously use.<\/p>\n
To be fair, in Ruby, this isn’t quite the same as in Java. Ruby will allow duck typing, which means that we don’t have to write an Interface. Also, Ruby doesn’t support Interfaces at all<\/a>, so that aspect of this is missing. Still — the principle\u00a0behind decoupling does make it very easy to write readable code, and testable code, and I\u00a0always love that.<\/p>\n","protected":false},"excerpt":{"rendered":"
Dependency Inversion is one of the five SOLID OO principles that’s become so popular in recent years (sometimes referred to as DIP). My opinion is that it’s a highly valuable concept, and is not well-named. “Dependency inversion” doesn’t mean a great deal on its own, and a lot of attempts to explain it tend to … Continue reading “Dependency Inversion Principle”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"image","meta":{"footnotes":""},"categories":[145],"tags":[],"_links":{"self":[{"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/posts\/659"}],"collection":[{"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/comments?post=659"}],"version-history":[{"count":10,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/posts\/659\/revisions"}],"predecessor-version":[{"id":669,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/posts\/659\/revisions\/669"}],"wp:attachment":[{"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/media?parent=659"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/categories?post=659"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.timrosenblatt.com\/blog\/wp-json\/wp\/v2\/tags?post=659"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}