1
\$\begingroup\$

I'm working on a few features for a strategy engine I'm making. I'm trying to figure out the best spots to separate the components, as either option will provide the same amount of coupling, with the same effectiveness.


For example, all players have a Damage component, a Player component, and a HealthBar component:

abstract class Damage
{
    protected abstract void sendDamage(Player targetPlayer, int rawDamage);
    public abstract int calculateRawDamage(Attack attackUsed);
    public abstract void receiveDamage(int rawDamage);
}

class Player
{
    List<Armor> equippedArmor;
    List<Buffs> currentBuffs;
    public Damage damageComponent;
    public List<HealthBars> healthBarComponents;
}

abstract class HealthBar //can be inherited for mana or health bar
{
    protected Color color;
    public float percent; //0.0 - 1.0
}

When a player receives damage, I need to show a red number floating up from their head, indicating the amount of damage. This can either be implemented in HealthBar, or in Damage. It fits damage better, but then healing works in the same way, and wouldn't be called from damage. I could abstract damage into something like ChangeValue, which would change mana, health, etc in any direction, or I could use the abstract HealthBar class to show this number being changed.


I'm trying to think of a general rule that would solve this and other problems, where two classes use the same function equally. This is an oversimplified version of my classes, but it makes more sense this way.

How should I handle functions, where two classes have equal use?

\$\endgroup\$

1 Answer 1

4
\$\begingroup\$

I think you kinda just answered you own question. The number needs to appear not only on damage but also on heals, i.e. it appears whenever your health changes. And your Damage component has no connection with heals. So they don't really use the same functionality equally.

Because of that I think I would make it a part of your HealthBar. Make it react automatically to any variation in the health bar, and show that variation as a number in green or red depending on whether it increased or decreased. Besides, the HealthBar is by nature a GUI component, and so is the damage number you want to show. On the other hand Damage is conceptual.

But your HealthBar seems to be only holding a percent value at the moment. This would make it harder to know which number to show since there's no absolute range. Because of that I would also change it into a value + max pair instead, and keep it synced with the player's health.

Nonetheless, you might still want to generalize your Damage component a bit further too, to enable applying any sort of stat variation like you mentioned.

The bottomline is...

If and when both options really provide the same amount of coupling, then it doesn't matter where you add the functionality. Just pick the one and move on, since none of them will have a benefit over the other. Try to choose the one at the closest level of abstraction though.

\$\endgroup\$
1
  • \$\begingroup\$ Seperating this functionality into it's own class and providing an interface with a "PopupHealthChange" method may be viable for reducing coupling. \$\endgroup\$ Commented Jun 12, 2017 at 10:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.