Notifications
You’re not receiving notifications from this thread.
Open Closed Principle Discussion
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.
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.
