Talk:Equals vs the Encapsulation Boundary
This is the result of a group discussion between Ben, Alex, Matthew, Michal and Stephen --Matthew Harward 05:08, 30 July 2009 (UTC)
I would agree with Wal that you shouldn't need equals() often in the case where you are simply checking to see if two objects are the same object. However, this still leaves the equivalence case, which I think is much more reasonable. I disagree that the equals() method is likely to only be checking things which are publicly accessible. I think that much of the time equals() will be checking private things. In this case I would ignore the evil of class encapsulation, and simply use it to our advantage. In languages which don't even allow class encapsulation I'm at a loss. --Aidan 09:56, 1 August 2009 (UTC)
Since Java allows incest on your siblings, I'd probably use that for equals() without writing getters for all the private/protected fields. As long as one only reads from those fields, not much damage is done. However, I still think that this (incest) is quite evil. Maybe if a programmer uses it only for that equals() case it might be ok ... I've done most of my projects in C++ and Python and I have to say that I never missed accessing private attributes of other objects (I used C++'s friend ability many years ago but I think it's pretty bad as well). --TobiW
I like the application of Tell, Don't Ask which came up in today's lecture. It's mentioned on the page, albeit a little briefly. Why not just require that some values are passed in to the equals method? This completely avoids the need for getters, however it does make using the equals method quite messy. This means that if you were to change the criteria for two objects being equivalent, you may need to change calls to the equals method in several cases. However, with appropriate use of your editor/IDE these sorts of changes are trivial. --Aidan 02:27, 3 August 2009 (UTC)
I guess that this application might be the only one where incest is actually a good thing (please keep that sentence in this context). For languages where there is a real object encapsulation, the best way might be to implement equals methods for every attribute of the class, that way we indeed Tell, Don't Ask, but it's seriously going to get a class heavier ... Maybe by using polymorphism over the equals method if you only have one member of each type and no recursivity, this can be a bit cleaner ... not really sure though. --Bertrand Roussel
Why does everybody think class encapsulation is so evil? I would argue that class encapsulation is necessary in order to implement the equals() method. (Wal says that the equals() method should never be implemented, but his Avoid equals page lists the Location class with a latitude and longitude as an example. I would generalise this to include all data classes, which can be considered to have a "value" but no "identity". Therefore, the equals() method is necessary). As Aidan said, the equals() method will almost certainly need to compare fields that are not publicly exposed. Consider a car: its public interface shouldn't reveal everything about itself. Many details of the engine should arguably be kept private to avoid interface pollution and satisfy Tell, don't ask. However, these values may be necessary to determine whether the car is identical to another car. Obviously here I'm using the "Equivalence" definition of the equals() method. --Joey Scarr 03:03, 16 July 2010 (UTC)
You haven't really justified why you need an equivalence method. You definitely need class encapsulation to implement a non-trivial deep comparison, but what is a case where you would need to know whether they are equivalent beyond observable properties? If you can check whether two objects are identical (in the sense of having the same identity), and you can check whether they are publicly equivalent, is that not enough? For instance, in the random number generator example, what does it matter whether they have the same seed and are at the same stage of their generation presently? They probably won't be in future. Besides, (pseude)random numbers are supposed to be unpredictable. --Lukas Korsika 10:11, 16 July 2010 (UTC)
