Private is private. The real question is how much could break by short-circuiting its internals.
But also, overthinking it will not help to advance. Start with a simple design, yet sufficiently clear for not having to rely on the internals. If it gets more complex, refactor and prefer composition over inheritance.
Class represent a whole with some invariants, and here some parts are missing: in the real code you would probably have some means to initialize
baseHp probably in the constructor. And you would have ways to change
baseHp, for example incrementing or decrementing it with some methods such as:
Your shortcut could then lead to an inconsistent behavior, where some part may rely on the private implementation and some on the override of the public method. Maybe even at some time the monster will think being dead while the
getHp() still insolently returns 100.
The basic advise here, is not to interfere with the base class internal business. This is by the way called "history constraint"
Four solutions in your case:
- expose updater of hp in the base class, ensure that no other method changes the private hp value. Then make sure special monster get its hp initialized as needed and override its hp change methods.
- outsource hp management using the strategy pattern. Classes would have a default strategy and special monster a special strategy. This would by the way allow for fine tuning the gameplay with the strong monster, e.g. multiplying the increases of hp, but making it still more difficult to decrease it. When this approach is used also for other behaviors, it naturally leads to the entity component system pattern, a popular design in gaming industry.
- change your base class to allow some phantasy for the derived classes about the hp. The template method design pattern will be your friend. But this adds a lot of complexity and seems overengineered if just to handle a few exceptions.
- Deepen your class hierarchy with an abstract
rawBaseMonster without internal implementation for hp, and let
baseMonster inherit from it. special monster would inherit from raw. But this will lead to complex hierarchies, and quickly you'd realize that there are all sorts of other exceptions, and redundant branches. Clearly a sympto that inheritance was overused. Sooner or later you'd come to the entity component system.
The key to your problem is to think carefully about how the state of your base object is to be used by its children. Do not to overengineer it from start, or you'll risk to end up stuck in thinking. Start with your base class, clean it to expose the hp management better, and refactor only once you really need it.