I think I probably focused on a different point than your first comment. I agree that avoid unnecessary exceptions that could lead to invalid states is better. In order to avoid it, one could still make this methods no-ops that log messages informing that they were called.
The point in using an interface is that in my team we usually see the software in a lifecycle of code -> stabilize -> protect -> experiment. In that way, introducing new methods, changing the interface, in a domain we already understand the behavior would make the need to introduce breaking changes to code that is already stabilized and protected instead of just replacing an implementation detail. Although, if it is a domain we don't have a grasp yet, this approach would certainly be used.
Along with this, interpreting the methods as commands send to the object, a specific command be accepted (i.e. the method being in the interface) but not processed (i.e. it is a no-op) is a common pattern when following CQS or in CQRS architecture, which aligns with the event-driven approach of this design.
It is really nice to have this kind of feedback once this was the main drive for me to start writing. Thank you.
In some cases a no-op is fine - for a stretch I was a big fan of the null object pattern - but in this particular case I'd honestly rather see an exception than a no-op. I can see myself being that idiot coder who skipped the docs and is tearing his hair out wondering why my un-baked pizza isn't delivering.
I'm also seeing myself as increasingly old fashioned though - I'm not a fan of dynamic languages because I want this kind of type safety we're discussing - so I may not be able to fully see your side of it.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.