Skip to main content

Open Closed Principle Discussion

General • Asked by Chris Oliver
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?

References:
https://github.com/rubocop-hq/ruby-style-guide/issues/458
http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/

Thanks!

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!


Login or Create An Account to join the conversation.

Subscribe to the newsletter

Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.