Properties are not intended for providing access to a private attribute. Properties are intended to give you the option of making zero-argument methods accessible as if they were attributes, so that a given "attribute" can be implemented as either a calculation or an actual attribute, without changing the interface of the class.
As such, it's usually not really a question of "better", but rather a design decision with pros and cons that depend on the context.
In this case, whatever this object is supports x.hunger
, x.boredom
and x.mood
. Why not x.mood()
? You could, although that exposes permanently in the interface that it is a calculation and is not stored.
If a prior version of the class had a "real" mood
attribute, and a required invariant of the object meant that any internal method updating boredom
or hunger
had to also carefully set mood
to be consistent, then introducing the property would be an excellent refactor; the interface stays the same, but the invariant is now guaranteed to always hold, rather than having to be carefully maintained. A whole field of bugs are made impossible to occur.
On the other hand, if mood
is expensive to calculate, or has side effects, then it likely would be much better as a normal method. Making it look like an attribute access means that client code programmers will likely think of it as an attribute access, which is cheap and non-destructive; this would be a rich source of bugs or performance problems.