Today’s show marks our reaching of the final letter in our discussion of SOLID, the D, which stands for the Dependency Inversion principle! We kick things off with a bit of research on exactly what the Dependency Inversion principle states, and from there we unpack what implementing it in the real world might look like. Our conversation is all about the idea that pieces of your code should be decoupled and you can do this using interfaces. We discuss how the Dependency Inversion principle might be applied when you are connecting to databases, how it relates to inversion of control, and ways of implementing it other than dependency injection. We finish off the show by referring to the Manifesto for Software Craftsmanship, a beautiful parchment cementing developer best practices in true Web 2.0 style, so join us for the ride and hear about the final ingredient in our juicy SOLID sandwich!
Key Points From This Episode:
Transcript for Episode 169. SOLID -Dependency inversion principle
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host to day.
[0:00:09.3] DA: Dave Anderson.
[0:00:10.1] MN: And our producer.
[0:00:11.3] WJ: William Jeffries.
[0:00:13.1] MN: Today, we’re lastly talking SOLID with the dependency inversion principles.
[0:00:18.8] DA: It is the ultimate principle.
[0:00:21.0] MN: The final principle, we at the end of the D in SOLID and we’re getting ready to discuss it, as we’re looking up examples and what not and I think you know, going on this journey, definitely have seen ways that I could improve the code that I write to the best of my abilities. Let’s jump right in.
Dave, are you familiar with the dependency inversion principle.
[0:00:45.8] DA: I believe I’ve used it once or twice in my life.
[0:00:49.9] MN: According to Wikipedia, the principle states two things, it’s two fold this principle. Wants to be very verbose in what it does so A, high level modules should not depend on low level modules. Both should depend on abstractions, eg, interface, that’s the first one. And the second one is abstraction should not depend on details.
Details, concrete implementations, should depend on abstractions. Anyone have a thoughts on what that means to them and how do they end up using the dependency inversion principle?
[0:01:25.6] DA: Sounds like we’re trying to decouple modules.
[0:01:27.6] MN: Yeah, it’s just like hey, interfaces shouldn’t depend on, should be abstracted but then the details should depend on those abstractions essentially is what it sounds like.
[0:01:37.1] WJ: I just use dependency injection.
[0:01:39.8] MN: Dependency injection, all the things. I think the idea is that you want to separate, it’s like a mechanism or principle to decouple your code so that they’re not like talking and communicating directly to each other, it communicates through an interface and I think there’s definitely other principles that we have spoken about and in our series or SOLID series that kind of helps you ensure that you're not talking directly to a particular class or object.
[0:02:07.1] DA: Right. I mean, I guess like you could do dependency injection but still depend upon like a concrete implementation. If you say, I will only accept your Postgres database connection for my service class than if one day, you know, you want to move away from Postgres and upgrade to the miraculous enterprise level database that is Oracle then you know, it’s going to be a lot of work for you, going to depend on the concrete details in addition to paying the bill of that expensive license for Oracle. You’re also going to have to pay your software engineers to reimplement all those things that depend on the details of Postgres. You could just use database connection interface instead of the concrete Postgres.
[0:02:54.1] MN: Right, the idea is not like calling specific calls that pertain to one particular technology but then making an interface that has like connect and you know, close and those kind of things in which then whether you’re using Postgres or Oracle can respond to those things. My son is very interested in this database connection conversation.
[0:03:22.6] DA: He’s hanging out, he’s like crunch the keyboard.
[0:03:27.2] MN: Yes, DB connections, Oracle, enterprise.
[0:03:30.7] DA: That’s his thinking sound, right? Thinking. Yeah, I think he was like thinking that you know, my thought that a lot of these topics that we were talking about with SOLID is kind of like peanut butter and jelly, they go really well together which is like –
[0:03:48.2] MN: Yeah.
[0:03:51.3] DA: We were talking earlier about design by contract which is kind of like related to the liskov substitution principle and this dependency inversion principle is kind of related to the idea of inversion of control or which dependency injection is one of those things.
Yeah, if you have this contract that you’re injecting and they’re inverting control with then boom? You have that principle going and it’s the tasty sandwich.
[0:04:26.9] WJ: You're making me hungry.
[0:04:29.2] MN: BRB, got to make a sandwich. Yeah, I think a lot of these principles that we’ve been going over definitely depend on each other and this one in particular, the idea that you shouldn’t be super specific with the layers that you're communicating across but instead, having interfaces to have methods that will be implemented so that you can then communicate across those layers is definitely from as you mentioned, liskov and now this. Then you also have you know, the interface specificity principles that ensures that you’re only calling one or two of those methods within an interface rather than implementing 17 of them as we discussed previously in our episode about that.
I think it just makes the code a lot cleaner because Dave mentioned with you want to move from one database application to another, you wouldn’t have to break your neck.
[0:05:24.9] DA: Right, I guess the specificity thing like if you’re using the connection, the database connection to do a query then maybe you don’t want the even the option of depending upon the closed database connection method like you just don’t need it. Don’t even put it on the table.
[0:05:46.4] WJ: What exactly is the difference between dependency injection and the dependency in inversion principle?
[0:05:53.6] MN: It sounds pretty much the same, it’s using the same words, that’s kind of confusing. But I think dependency inversion principle is a more general idea of saying, “hey, things should be decoupled and you can decouple them with interfaces. Whereas dependency injection is like a really specific way to do inversion of control which like we were talking about before like the peanut butter and jelly inversion of control and design by contract kind of covering, will get you to, a good place with dependency inversion principle like dependency injection is one way to do inversion of control.
Just a quick Google here, there are a couple of different ways that you can do inversion of control but besides dependency injection which is a pretty common one, that’s the one that I often reach for.
[0:06:58.5] WJ: What are the others?
[0:06:59.7] DA: I am seeing on the old Google here that there are other patterns called plug-in or service locator that can also achieve similar ends. I would love to have another podcast episode about the service locator because I don’t know exactly what it is. You have to be able to hand wavy but you know, it is like there are other ways to do it but it is like, it depends on the injection if it is very straight forward. You just put it in there, you construct your objects and inject the dependency in the constructor. How could it be easier? And then you know also we get the benefit of testing and all of that.
[0:07:37.6] WJ: Yeah, I was going to say that makes testing a lot easier when you can inject the mock of the dependency rather than having to deal with the complexity of the actual dependency.
[0:07:46.0] DA: Right, which the reason why injecting the mock satisfies things is because we are adhering to this dependency inversion principle not depending on the concrete thing just depending on the abstract thing but I guess there is an even more abstract layer of different ways that you could go about achieving those means.
[0:08:12.6] WJ: So as long as the mock implements the same interface as the actual dependency then you’ve satisfied the dependency version principle.
[0:08:20.7] MN: Yeah, I think with the studying of SOLID and the understanding of all the different principles, I think if you’ve got the baseline of all five then you can be a much better developer than someone who doesn’t understand SOLID but Dave recently found a manifesto website called Manifesto.softwarecraftsmanship.org.
[0:08:46.9] DA: Oh yeah it is pretty dope. It is like Web 2.0. I’m pretty sure they use Ajax, it was made in 2008 and it looks like a parchment scroll. It is pretty cool.
[0:08:58.8] WJ: Yeah, it’s got a little animation effect. I am pretty hyped about it.
[0:09:03.4] MN: I’m ready to sign it people. I don’t know about you all but I am. I think that they are going over SOLID and explaining different principles. I think I have to now make it official on this website. I’m so excited guys I am going to do.
[0:09:20.7] DA: You value the well-crafted software.
[0:09:22.8] MN: Yes.
[0:09:24.0] WJ: I signed it.
[0:09:25.0] MN: Yeah. Not only working software but also well-crafted software yes, SOLID would get you that for sure not only responding to chain but also steadily adding value. We did, we renamed one of the SOLID principles for responding to change. We did this together not only individuals at interaction but also a community of professionals. Thanks you guys for joining me every week to talk about things like SOLID. We are a community and not only customer collaboration but a productive partnership.
[0:09:57.9] DA: What else is a productive partnership if not this podcast?
[0:10:01.1] MN: Exactly. I am signing the manifesto if you are listening in, sign it at listening to the SOLID series that we currently have.
[0:10:11.8] DA: Look for my signal Bobby Crouton.
[0:10:16.7] MN: Oh man, no it is going down. I am doing it. It is happening. I think going over this SOLID principle, it is definitely a good conversation to have to ensure that keeping above my toes in these different principles. I am curious, I am sure there are other different principles out there in the world of software development and I am curious, have you all heard of different ones that we could potentially go over?
[0:10:39.3] WJ: I can’t really think of any catchy acronyms but like SOLID although I have noticed that SOLID seems to be mostly a Java thing. You don’t really hear people talking about SOLID much outside the Java community. So you’d think that the other communities wouldn’t have something equivalent.
[0:11:00.1] DA: I mean yeah when you have static types and you got to think about the design patterns and application of these kind of concepts a little more closely because you have to name everything and have a very specific structure with other languages like it’s all ducks.
[0:11:18.0] MN: That’s all ducks.
[0:11:20.0] DA: But it can still help. It can still help to think about this.
[0:11:23.9] MN: Guys, I signed it. It’s official.
[0:11:29.8] DA: All right, we’ll find another manifesto for you to sign next podcast episode.
[0:11:34.3] MN: Hey, we got to go through another one of these.
[0:11:36.8] WJ: If you guys have any manifestos for us to sign, please tweet them at us. We love signing manifestos.
[0:11:44.1] MN: Let it be software related please. I don’t want it any creep manifestos showing up on Twitter.
[0:11:51.1] DA: Is there like a Communist Manifesto or something.
[0:11:54.0] MN: I don’t want to sign that one people, I want to sign software maybe Agile.
[0:11:58.8] WJ: Yeah, it’s got to be software and you used to be able to sign the Agile manifesto online and now it’s inside like they locked it. I don’t know if the database is full or what happened.
[0:12:10.2] DA: They’re just like, “We’re good.”
[0:12:11.3] MN: You know we got enough signatures bro.
[0:12:13.3] DA: I am going to come up with the Agile Communist Manifesto.
[0:12:17.1] MN: Oh gosh.
[0:12:17.7] DA: I know that will be offending for you to still sign it.
[0:12:22.0] MN: Oh man.
[0:12:22.9] WJ: From each method according to his ability to each method according to its need.
[0:12:31.7] MN: If you guys have any manifestos or any acronyms we should go over, I would be more than happy to dive down into the world of acronyms to raise the bar on my software craftsmanship as the signature I just signed right now.
[0:12:50.1] DA: You got to go deeper.
[0:12:51.2] MN: Anything helps, anything will help and we’ll see you on the next one.
[END OF INTERVIEW]
[0:12:56.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
