> If you imagine a game that has characters, relationships, items, spells, and so on, it's often not that easy to model as encapsulated objects. Does each character have a list of other characters that they have a relationship with? What happens when you want to change the relationship, or a character casts a spell that temporarily changes the relationship? Can easily end up a mess, because it's not obvious where such things should live in >an OO model.
It's not really that hard. You just have one RelationshipManager that every Character have access to via simple public methods. OO is not so bad, especially when you forget about inheritance and use composition.
> And that data is no longer belonging to the instance now.
It belongs to the correct instance. The noun in the domain to which the information logically uniquely belongs is a relationship, not a character (of which there is typically more than one with different roles in a relationship, the number and roles varying by type of relationship.)
One problem that textbook OOP examples produce is that they tend to favor a heirarchy of physical entities as examples, which has the virtue of familiarity but really obscures the analysis of nouns in the domain, the most important of which in most real domains are the nouns describing relationships, activities, and events.
The same thing can apply to every other property I think? probably you can seperate the User::name into a PersonIdentityProperty something like that, and remove the type limit to allow it to contain any property. Then it is basically a ecs now. And that do actually has some pros. People can have multi name, you system at least works properly with it now(and for free).
But splitting it out into another class is halfway there already, no? The relations object doesn't correspond to a real domain object anymore. Next step is just to split out all the other components.
You could say that about anything you construct in your model though? Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?
I could write the whole thing as an ECS and call all the objects systems or components, and then they are nouns in the domain?
> You could say that about anything you construct in your model though?
That’s kind of the point, yes, model -> nouns -> objects.
> Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?
There’s nothing particularly vague about “noun in the domain”; linguistic-based modelling certainly isn’t the be-all and end-all of OOP modelling, but its one of the traditional approaches dating back to the early 80s and its more sophisticated than thr kind of naive tangible-item approach that seems to be set up as a strawman here.
> I could write the whole thing as an ECS and call all the objects systems or components, and then they are nouns in the domain?
A relationship is a real thing in the domain being modelled, “systems” and “components” are (in the sense you are using them) not, unless the thing you are modelling is a an ECS implementation of a domain. There might be some utility for such a second-order model in OOP (if the OOP is for a code generator, for instance), but it wouldn’t be a model of the domain addressed by the ECS system, but of the ECS system itself.
It's not really that hard. You just have one RelationshipManager that every Character have access to via simple public methods. OO is not so bad, especially when you forget about inheritance and use composition.