All threads / Open Closed Principle Discussion

Ask A Question

Notifications

You’re not receiving notifications from this thread.

Open Closed Principle Discussion

Dicussion for Open Closed Principle
Loved the bla bla bla on minute 8ish :)
Great video! Thanks
Reply
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.
Reply
this is fantastic, more like this please
Reply

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!

Reply
Join the discussion

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

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

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

    logo Created with Sketch.

    Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

    © 2020 GoRails, LLC. All rights reserved.