Dependency Inversion Principle

This episode covers the D in SOLID, the Dependency Inversion Principle (DIP). In it, you'll learn why you might want to inject a class' dependencies and how to do so. Additionally, we'll show how following this principle makes it easier to follow ...
This is a companion discussion topic for the original entry at
1 Like

@jferris @benorenstein thanks for another great episode. Could we start to have example codes that shown in the episode links in show note?

1 Like

Any recommendations on dealing with cascade dependencies drawback? Doesn’t happen that much though sometime feels like there could be a better solution.

Just interesting how you guys dealing with those :smiley:

Thanks in advance!

Could you be more specific? I’ll give it a shot. I am very concerned about dependencies, external and internal when I code. I am just not sure what you mean by the cascading deps.

Sure, I meant the drawback @jferris mention at the last minute or two of this episode, i.e. …at some level you need a place to configure all of those dependencies.

They mentioned the facade pattern shortly. So, for example you could do this if you don’t want to care about the details of your use cases every time you execute them:

class App <, :mailer)
  def create_todo(request), mailer, request).call

The dependencies aren’t “cascading”, though. Do you have any concrete examples you’d like to clean up?

btw. Great episode. Thanks guys!

Loved the way you used decorators and collection objects and the comparison with mixins. Great episode!