re: Difference between state and State VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I can see that. My personal preference is to prevent the need for exceptions as much as possible; if there's some way to keep the application from ...

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.

code of conduct - report abuse