I don't know PHP, but I do know, in order of most to least knowlesge, C++, Java, and C#.
Seems to me that setters and getter being required for your object to work well might be a symptom of objects that can be better designed. If you're working with employees, for example, the employee object should have logical methods that do logical things to them. For example, promote, or get a standard format legal name. When you sort and search through bunch of employees by some attribute, wouldn't it be better to work with a data structure object instead? This way, checking employee membership in some entity is an action on the data structure. Not to say this would be how everybody would design an employee object, it depends on the use case. The big picture is, if you need to work with a set of objects, maybe use a data structure object. If you manipulate single objects, probably more useful to put those methods in the single object's class.
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.
I don't know PHP, but I do know, in order of most to least knowlesge, C++, Java, and C#.
Seems to me that setters and getter being required for your object to work well might be a symptom of objects that can be better designed. If you're working with employees, for example, the employee object should have logical methods that do logical things to them. For example, promote, or get a standard format legal name. When you sort and search through bunch of employees by some attribute, wouldn't it be better to work with a data structure object instead? This way, checking employee membership in some entity is an action on the data structure. Not to say this would be how everybody would design an employee object, it depends on the use case. The big picture is, if you need to work with a set of objects, maybe use a data structure object. If you manipulate single objects, probably more useful to put those methods in the single object's class.
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.