Talk:Equals vs the Encapsulation Boundary
| Line 4: | Line 4: | ||
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). --[[User:TobiW|TobiW]] | 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). --[[User:TobiW|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. --[[User:Aidan Bebbington|Aidan]] 02:27, 3 August 2009 (UTC) | ||
Revision as of 02:27, 3 August 2009
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)
