Ask A Question


You’re not receiving notifications from this thread.

Open Closed Principle Discussion

Discussion for Open Closed Principle
Loved the bla bla bla on minute 8ish :)
Great video! Thanks
Quick question Chris, when you were building out functionality like this for Hatch, how much of this structure do you plan versus how much did you arrive at through refactoring and iteration? 
For most of this, I knew there was going to be a lot of code so I'd start doing the single responsibility work separation of this code into its own files and folders first. I didn't build this multi-provider thing out until I supported more than just DigitalOcean. 

It's really easy to refactor your code into this, so it's not something you need to start with ahead of time. In fact, trying to follow design patterns too early is often one of the easiest ways to end up with confusing code. Refactoring to apply patterns later on is usually the best approach.

fantastic piece of advise!

this is fantastic, more like this please

Hi there! I have a question about raising NotImplementedError.

I see "raise NotImplementedError" in the abstract class, but some people suggest not to use it. Instead, they add documentation and remove the methods. However, I think raising error in abstract methods is beneficial to those who use IDEs such as RubyMine to increase productivity with its code completion and inspection for method existance.

Could you share your opinions on which approach to use?




I definitely think you should raise some error, it doesn't have to be NotImplementedError. The main reason you want to do that is because it provides a clear explanation why something didn't work.

You don't want to assume people are going to read the docs and implement every method correctly on the first try. It's very likely that won't always be done perfectly. Raising the error helps guide the developer on how to properly implement their subclass which is very helpful. I don't use and IDE, but if there are benefits there, then that's another reason that makes it more intuitive to use for other developers.


I couldn't agree more. Thank you Chris!


I am not sure but does this follow the Single Responsibility principle ?

Ideally to follow that principle also, would we need to create separate additional classes for Vultr DigitalOcean etc.. for example a class to add the ssh key second one to create etc.


Same thoughts. However, there has to be a limit as to what a "responsibility" is. To make it more general you would say it's to set up Digital Ocean. Otherwise you can keep abstracting the responsibilities until you just have one line files. I think more in moderation especially for the framework.

Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,329+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.