One rule of thumb for reusable, library-style classes is that private methods can make assumptions about internal state and/or the state of arguments, because their callers know everything, but public methods cannot because their callers often can't even see the internal state. Encapsulate the constraint in the class that best understands it.
Extending that, it can be important for public methods to perform these checks in order to guarantee that the internal state of the object remains consistent. It is less important (but still often valuable) for private methods to perform these kinds of checks, because they can trust the caller to understand the internal state itself.
However, for the case you give, I think your class really ought to let the calling code see that attacking right now is futile. Then the calling code has an opportunity to choose to do something more useful instead, rather than just issuing an attack order that is ultimately ignored. For this kind of thing, think of the principles behind the HATEOAS model - code shouldn't assume it knows what can be done next, it should ask the thing it's going to talk to what options are available, then pick one. This needs to be applied selectively, but I think game "AI" is one area that this logic applies well.
↧
