C ++ Getter / Setter (Alternatives?)

To be slightly opposite: yes, getters and setters (like accessors and mutators) are mostly evil.

The evil is not so much IMO, as much from "breaking encapsulation" as from simply defining a variable of one type (eg int

) when it really isn't that type at all. Looking at your example, you are calling Armor a int

, but it really isn't. While this is undoubtedly an integer, it is certainly not the int

one that (among other things) defines the range. Although your type is an integer, it never planned to maintain the same range as it int

does in general. If you want to Armor

have a type integer from 1 to 500

, define a type for direct representation and define Armor

as an instance of that type. In this case, since the invariant you want to apply is defined as part of the type itself, you don't need to bind an installer to it to try to enforce it.

template <class T, class less=std::less<T> >
class bounded {
    const T lower_, upper_;
    T val_;

    bool check(T const &value) {
        return less()(value, lower_) || less()(upper_, value);
    }

    void assign(T const &value) {
        if (check(value))
            throw std::domain_error("Out of Range");
        val_ = value;
    }

public:
    bounded(T const &lower, T const &upper) 
        : lower_(lower), upper_(upper) {}

    bounded(bounded const &init) 
        : lower_(init.lower), upper_(init.upper), val_(init.val_)
    { }

    bounded &operator=(T const &v) { assign(v);  return *this; }

    operator T() const { return val_; }

    friend std::istream &operator>>(std::istream &is, bounded &b) {
        T temp;
        is >> temp;

        if (b.check(temp))
            is.setstate(std::ios::failbit);
        else
            b.val_ = temp;
        return is;
    }
};

      

        
        
        
      

    

At the same time, the definition of some armor with a range of 1..500 becomes completely trivial:

bounded<int> armor(1, 500);

      

        
        
        
      

    

Depending on the situation, you might define (for example) a type saturating

where trying to assign an out-of-range value would be fine, but the value that is actually assigned will just be the closest value that is within the range.

saturating<int> armor(1, 500);

armor = 1000;

std::cout << armor;  // prints "500"

      

        
        
        
      

    

Of course, what I gave above is also slightly bare bones. It will probably be convenient for your armor type to maintain -=

(and possibly +=

) so that the attack ends with something like x.armor -= 10;

.

Bottom line: The main problem (or at least "one") with getters and setters is that they usually indicate that you've defined a variable as one type when you really need some other type, which is turned out to be kind of similar in several respects.

It is now true that some languages ​​(like Java) cannot provide the programmer with the tools needed to write such code. Here, I trust your use of the C ++ tag to indicate that you really want to write C ++. C ++ provides you with the tools you need and (at least IMO) your code will be better for you to efficiently use the tools it provides, so your type enforces the required semantic constraints while maintaining clean, natural, readable syntax.