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.

17 Dependency Inversion Principle

Episode 249 · June 13, 2018

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

Design Patterns


Transcripts

No transcripts available. Earn a free month

Discussion


Gravatar
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.

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

Gravatar
This is a great episode.  Everyone should learn SOLID

Gravatar

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


Gravatar

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.