more direct setters and getters can be useful at times too, mostly for higher level manipulation, they aren't inherently evil, but delaying the implementation till you actually need them should be the way I think
for a single player game these may not be needed unless a specific quest/story calls for that, but in VTT it's basically impossible to omit due to the freedom required by GM to manipulate the whole world, manipulating health only with damage and healing may get annoying
Even though a lot of these might be fundamental aspects of classes that several software developers already practice, I absolutely appreciate the tip about having the functions in your class appear in the order you are likely to call them. I agree that jumping up and down is irritating.
Totally agree with most of this. Not so sure about "one public method" per class. You'd end up with a very strange API like PlayerHealthIncreaser, PlayerHealthDecreaser. The you'd need to introduce an intermediary class PlayerHealthService to coordinate PlayerHealthIncreaser and PlayerHealthDecreaser. In the meantime, Health is a direct attribute of Player not an Item like a Shovel or Pickaxe that can transferred, dropped, aquired, etc.
Rather, I would prescribe something like "a few clearly cohesive public methods" like PlayerHealth.Increase(20), PlayerHealth.FullyHeal(), PlayerHealth.Decrease(20). Of course, you'd the have to use an Observer or similar to know when PlayerHealth was is various states and perhaps even the exact value of PlayerHealth. PlayerHealth.AddHealthObserver(IPlayerHealthObserver) and PlayerHealth.AddHealthStatusObserver...
more direct setters and getters can be useful at times too, mostly for higher level manipulation, they aren't inherently evil, but delaying the implementation till you actually need them should be the way I think
for a single player game these may not be needed unless a specific quest/story calls for that, but in VTT it's basically impossible to omit due to the freedom required by GM to manipulate the whole world, manipulating health only with damage and healing may get annoying
Even though a lot of these might be fundamental aspects of classes that several software developers already practice, I absolutely appreciate the tip about having the functions in your class appear in the order you are likely to call them. I agree that jumping up and down is irritating.
Totally agree with most of this. Not so sure about "one public method" per class. You'd end up with a very strange API like PlayerHealthIncreaser, PlayerHealthDecreaser. The you'd need to introduce an intermediary class PlayerHealthService to coordinate PlayerHealthIncreaser and PlayerHealthDecreaser. In the meantime, Health is a direct attribute of Player not an Item like a Shovel or Pickaxe that can transferred, dropped, aquired, etc.
Rather, I would prescribe something like "a few clearly cohesive public methods" like PlayerHealth.Increase(20), PlayerHealth.FullyHeal(), PlayerHealth.Decrease(20). Of course, you'd the have to use an Observer or similar to know when PlayerHealth was is various states and perhaps even the exact value of PlayerHealth. PlayerHealth.AddHealthObserver(IPlayerHealthObserver) and PlayerHealth.AddHealthStatusObserver...
PlayerHealthStatus.Low, PlayerHealthStatus.Dead, PlayerHealthStatus.Poisoned???,
etc.
Now PlayerHealth also needs something to manage the Poisoned effect. PlayerHealthEffect... oooo time to refactor!!!
Hope the tests allow it!