You are right in that objects consist of attributes, states, and behavior, if you define attributes to mean non-changing characteristics of an instance. As a matter of fact, it is important to make this distinction, because there exist objects which contain only attributes, (in your sense,) and no state; they are called immutable and they are very useful in programming.
This three-part definition is indeed represented in programming languages, for example using the final keyword in Java or the readonly keyword in C# to denote instance data which may not change throughout the lifetime of the instance.
I have to add, though, that non-changing instance data are usually not called attributes. We tend to speak of them as 'final' or 'readonly' or 'constant data' depending on which language we are using. The proper term for them would be 'invariants', but then this word is not frequently used in this sense; it is more often used for other things.
What you describe is known as an anemic domain model. As with many OOP design principles (like Law of Demeter etc.), it's not worth bending over backwards just to satisfy a rule.
Nothing wrong about having bags of values, as long as they don't clutter the entire landscape and don't rely on other objects to do the housekeeping they could be doing for themselves.
It would certainly be a code smell if you had a separate class just for modifying properties of Card - if it could be reasonably expected to take care of them on its own.
But is it really a job of a Card to know which Player it is visible to?
And why implement Card.isVisibleTo(Player p), but not Player.isVisibleTo(Card c)? Or vice versa?
Yes, you can try to come up with some sort of a rule for that as you did - like Player being more high level than a Card (?) - but it's not that straightforward to guess and I'll have to look in more than one place to find the method.
Over time it can lead to a rotten design compromise of implementing isVisibleTo on both Card and Player class, which I believe is a no-no. Why so? Because I already imagine the shameful day when player1.isVisibleTo(card1) will return a different value than card1.isVisibleTo(player1). I think - it's subjective - this should be made impossible by design.
Mutual visibility of cards and players should better be governed by some sort of a context object - be it Viewport, Deal or Game.
It's not equal to having global functions. After all, there may be many concurrent games. Note that the same card can be used simultaneously on many tables. Shall we create many Card instances for each ace of spade?
I might still implement isVisibleTo on Card, but pass a context object to it and make Card delegate the query. Program to interface to avoid high coupling.
As for your second example - if the document ID consists only of a BigDecimal, why create a wrapper class for it at all?
I'd say all you need is a DocumentRepository.getDocument(BigDecimal documentID);
By the way, while absent from Java, there are structs in C#.
See
for reference. It's a highly object-oriented language, but noone makes a big deal out of it.
Best Answer
Methods in most (class-based) OOP languages are fixed by type.
JavaScript is prototype-based, not class based and so you can override methods on a per-instances base because there is no hard distinction between "class" and object; in reality, a "class" in JavaScript is an object which is like a template for how the instances should work.
Any language which allows first-class functions, Scala, Java 8, C# (via delegates) etc, can act like you have per-instance method overrides; you would have to define a field with a function type and then override it in each instance.
Scala has another posibility; In Scala, you can create object singletons (using the object keyword instead of the class keyword), so you can extend your class and override the methods, resulting in a new instance of that base class with overrides.
Why would someone do this? There could be dozens of reasons. It might be that the behavior needs to me more tightly defined than using various field combinations would allow. It could also keep the code decoupled and organized better. In general however, I think these cases a rarer and there often is a more straightforward solution using field values.