当`healt`不能高于`maxHealth`时，如何在一个对象中定义`health`和`maxHealth`？

Question

I have a class called Warrior that has uint m_health and uint m_maxHealth attributes. I want my constructor to take parameters Warrior(uint health, uint maxHealth) .

Now I've studied C++ a lot and I know all the syntax etc, but it's hard to find tutorials on how to use the stuff etc. so I don't really know how should I define health and maxHealth when health obviously can't be higher than maxHealth :/

Here are few methods I thought of:

// method 1
Warrior::Warrior(uint health, uint maxHealth) :
    m_health((health > maxHealth) ? maxHealth : health),
    m_maxHealth(maxHealth)
{}

// method 2
Warrior::Warrior(uint health, uint maxHealth) :
    m_maxHealth(maxHealth)
{
    if (health > maxHealth) {
        m_health = maxHealth;
    }
    else {
        m_health = health;
    }
}

I'm sure there are other ways too. Sorry if this is just an opinion question, but if there's a "preferred" way in C++, what would it be?

Answer 1

If you intended to set the health during the game you might want to consider something like this:

Warrior::Warrior(unsigned int health, unsigned int maxHealth) :
    m_maxHealth(maxHealth)
{
    setHealth(health);
}

void Warrior::setHealth(unsigned int health)
{
    m_health = std::min(health, m_maxHealth);
}

Answer 2

There is a "better" way, depending on your definition of better. (And I'm guessing you mean "shorter" here)

Warrior::Warrior(unsigned int health, unsigned int maxHealth) :
    m_health(std::min(health, maxHealth)),
    m_maxHealth(maxHealth)
{
}

Answer 3

This is really more of a question on the design of the interface than the actual implementation. Both of the implementations in your code are similar and implement a design with a wide interface that allows for any combination of arguments.

A different approach would be to use a narrow contract on your constructor, in which the behavior of the object is well defined only if the obvious constraint that health < maxHealth is true. In that case you would document the constructor as such and implement it:

Warrior::Warrior(unsigned int health, unsigned int maxHealth)
  : m_health(health), m_maxHealth(maxHealth)
{
   assert(health <= maxHealth);
}

Which in my opinion is a better design. There is no good reason to accept the wrong arguments to the constructor. By adding that assert there you can detect early in the development cycle when your type is used out of contract. This is specially important with functions that have multiple arguments of the same type, as it will help detect if by mistake you pass the arguments out of order. The use of a wide contract there would reduce the maxHealth to be the same as the current health , and at a later time you will have problems trying to figure out why the Warrior is weaker than you thought it should be... the narrow contract will tell you the arguments are out of order immediately.

Answer 4

template <typename T>
class RangeBoundValue
{
public:
    RangeBoundValue(const T _min, const T _max) : _min(_min), _max(_max) {}

    void setValue(T val)
    {
        if (val < _min) _value = _min;
        else if (val > _max) _value = _max;
        else _value = val;
    }

    T value() const {return _value;}

private:
    const T _min;
    const T _max;
    T       _value;
};

Use this helper class inside Warrior

class Warrior
{
...
private:
    RangeBoundValue<uint> _health;
};

Answer 5

I would just put an assertion or throw exception in case precondition is not met:

Warrior::Warrior(uint health, uint maxHealth) :
    m_health(health),
    m_maxHealth(maxHealth)
{
    assert(health <= maxHealth); 
    // or throw exception
    throw std::logic_error("explanation");
}

I mean, what is the rational to decide for the caller which value to take? If caller puts health value bigger than maxHealth - it's violation of your class logic, so I would propose to fail immediately and inform caller about this. It should be problem in the software, so I think it's not desirable to hide it.

Exception or assertion is an explicit mechanism that will help you to find and recognise such problems early.

Answer 6

I am quite surprised that people are suggesting to throw exceptions when an argument list to the constructor is supplied with health>max_health. For instance, say you have some resurrection implementation where all creatures are resurrected with a fixed amount of health up to their maximum health and in some cases this exceeds maximum health, to avoid coupling you don't want this method to have to store every object's maximum health, you could add methods to test for it before submitting these arguments to the constructors but again this complicates things. Max health is usually implemented as a ceiling on health and given that this is a simple constraint, uncoupled from anything else, it should be the warrior's responsibility to enforce its own constraints.