In a Ruby base class such as Vehicle, how do you declare a method every subclass must implement, and what does raising NotImplementedError actually guarantee?

## Ruby has no abstract methods Ruby has no `abstract` keyword and no interface declaration that the interpreter checks. A **base class** that expects subclasses to fill in a method therefore writes a **stub**: a normal method whose only job is to fail loudly if it is ever reached. ```ruby class Vehicle def summary "#{self.class.name}: #{range_km} km" end def range_km raise NotImplementedError, "#{self.class} must implement #{__method__}" end end class ElectricCar < Vehicle def range_km = 420 end class Scooter < Vehicle; end ElectricCar.new.summary # => "ElectricCar: 420 km" Scooter.new.summary # NotImplementedError: Scooter must implement range_km ``` This is the **template method** shape: `summary` in the base class calls a **hook** (`range_km`) that each subclass supplies. The stub makes the hook visible to readers of `Vehicle` and gives a precise failure. ## Writing a useful stub - Use `self.class`, not a hard-coded `Vehicle`, so the message names the subclass that forgot the override. - `__method__` returns the current method's name as a symbol, which keeps the message right if the method is renamed. - Keep the stub's parameter list identical to what overrides will take; RuboCop's `Lint/UnusedMethodArgument` has `IgnoreNotImplementedMethods: true` by default, so unused arguments in a method that only raises `NotImplementedError` are not reported. - Do not make the stub return `nil` or call `super`: `nil` defers the failure to somewhere far away, and `super` ends in a `NoMethodError` that blames the base class. ## What the stub does not guarantee | Expectation | Reality | |---|---| | Checked when the class loads | No: only when the stub is called | | `Vehicle.new` is refused | No: the base class is still instantiable | | `respond_to?(:range_km)` is `false` for a subclass that forgot | No: the stub is a real method, so it is `true` | The `respond_to?` row surprises people because the core docs mention a case where it is `false`: methods such as `fork` that the C runtime marks as unimplemented on the current platform report `false`. A Ruby-level stub that raises is not such a method, so duck-typing checks see it as present. ## Choosing the error class `NotImplementedError` is documented as "raised when a feature is not implemented on the current platform", and it descends from `ScriptError`, not `StandardError`. Using it for abstract stubs is a long-standing convention, but it is borrowing a class meant for something else, and how it interacts with a bare `rescue` belongs to the exception hierarchy. Many codebases therefore define their own error, for example `class AbstractMethodError < StandardError; end`, and raise that. Either choice is defensible; mixing both in one codebase is not. ## Three ways to leave a hook for subclasses | Approach | Failure when a subclass forgets | Visible in the base class | |---|---|---| | No method in `Vehicle` at all | `NoMethodError` raised from inside the caller | no | | Stub raising `NotImplementedError` | `NotImplementedError` naming class and method | yes | | Stub raising a custom `StandardError` subclass | your own error class, named for the contract | yes | All three fail at the same moment, the first call. The stub variants add documentation and a better message; they do not add an earlier check. ## Enforcing the contract for real Because Ruby checks nothing up front, enforcement has to come from tests: 1. Keep one shared contract test (an RSpec shared example group or a Minitest module) that every concrete subclass runs. 2. Or loop over an explicit list of concrete classes and call each hook once, so a subclass still carrying the stub fails in CI rather than in production. 3. Prevent direct use of the base class if that matters, for instance by making its constructor private, which is a visibility decision rather than an inheritance one. ## Why interviewers ask it The question separates candidates who know the idiom from those who know its limits. A strong answer writes the stub correctly, explains that it is a runtime tripwire rather than a compile-time rule, notes the `respond_to?` and error-class caveats, and says how a team actually catches a missing override before production does.