Using getter/setter vs “tell, don't ask”?

Question

Tell, don\'t ask principle here is often pasted to me when I use getters or setters, and people tell me not to use them. The site clearly explains what I should and what I shoul

Answer 1

Well, if that's so, why bother with getters and setters after all? You can just have public fields.

void Attacker::attack(Warrior *target)
{
    target->health -= m_damage;
    target->armor -= 20;
    // wait 5 seconds
    target->armor += 20;
}

The reason is simple here. Encapsulation. If you have setters and getters, it's no better than public field. You don't create a struct here. You create a proper member of your program with defined semantics.

Quoting the article:

The biggest danger here is that by asking for data from an object, you are only getting data. You’re not getting an object—not in the large sense. Even if the thing you received from a query is an object structurally (e.g., a String) it is no longer an object semantically. It no longer has any association with its owner object. Just because you got a string whose contents was “RED”, you can’t ask the string what that means. Is it the owners last name? The color of the car? The current condition of the tachometer? An object knows these things, data does not.

The article here suggests here that "tell, don't ask" is better here because you can't do things that make no sense.

target->setHealth(target->getArmor() - m_damage);

It doesn't make sense here, because the armor has nothing in relation to health.

Also, you got it wrong with std lib here. Getters and setters are only used in std::complex and that's because of language lacking functionality (C++ hadn't had references then). It's the opposite, actually. C++ standard library encourages usage of algorithms, to tell the things to do on containers.

std::for_each(begin(v), end(v), my_func);
std::copy(begin(v), end(v), begin(u));