Yes :D there may be sorting happening inside an aggregate entity and that membership in a collection needs to be checked whether we are dealing with objects or data structures. However the objects in a collection usually only serve one aggregate, eg. Match / Events. That's why ordering algorithm can be coded into a compareTo -method of that object inside the collection. No need to order based on exposed attributes.
Oh, OK. Yeah I agree with you; for modularity and stability, it's better to opaquely define how comparison should work than to expose data and let the user misuse and depend on that data. I think the big disagreement most people have with that idea is that encapsulation isn't always the most important thing in the world.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some collections contain data structures, some contain objects.
Footballing example:
Sorry, I'm not sure if you're trying to make a point or not?
Yes :D there may be sorting happening inside an aggregate entity and that membership in a collection needs to be checked whether we are dealing with objects or data structures. However the objects in a collection usually only serve one aggregate, eg. Match / Events. That's why ordering algorithm can be coded into a compareTo -method of that object inside the collection. No need to order based on exposed attributes.
Oh, OK. Yeah I agree with you; for modularity and stability, it's better to opaquely define how comparison should work than to expose data and let the user misuse and depend on that data. I think the big disagreement most people have with that idea is that encapsulation isn't always the most important thing in the world.