Skip to main content

Subscribe to GoRails to get access to this episode and all other pro episodes, and new awesome content every month.

Subscribe Now
Only $19/month

Unlimited access. Cancel anytime.

18 SOLID Design Principles in Rails:

Dependency Inversion Principle

Episode 249 · June 13, 2018

Abstractions should not depend upon details. Details should depend upon abstractions

Design Patterns


No transcripts available. Earn a free month


Thank you for these quality episodes. We definitely want to see more episodes like this. It would be nice to see them how they are applied to real-world projects. How to create the folder structure and apply all these principles there.

I want to see more of this kind of stuff. I've now let you know in the comments below the video. :-)

This is a great episode.  Everyone should learn SOLID


Thanks for the eposide.
I don't understand why there is a need to say :digitalocean) (last line in code)
Shouldn't the provider be encoded only by the object passed to the perform method ?


So in here I see you're passing the Server::Create object an argument with the provider, which is something it already has (since it's in the server, and the Server::Create object knows the server).

This creates the possibility that someone might eventually try to call #perform(:linode) on an instance that has a :digital_ocean as the server.

Do you think we should depend on documentation and testing in these cases?
If I have a passing test verifying this case is correctly handled, I think it'd be OK.

Login or create an account to join the conversation.