WebSitesOfNote

GetterEradicator: " GetterEradicator design 22 February 2006 You can tell them by the twitch in the left hand side of the mouth when they see a getter method, there's swift pull on their battleaxe and a satisfied cry as another getter is hewn unmercifully from a class which immediately swoons in an ecstasy of gratefulness at the manly Getter Eradictor's feet. Alright, maybe my return to English beer is affecting me a bit too much, but Chris's gentle tweak struck a pet peevlet of mine. I've often come accross people who tell you to avoid having getting methods on classes, treating such things as a violation of encapsulation, Allen Holub's article is one of the best known. The general justification is that getters violate encapsulation. If I've got a bowler class with fields for overs, runs and wickets, then adding getters (getOvers, getRuns, getWickets) is little better than just making the fields public. There's some sense to this argument, and I certainly suggest that you shouldn't write accessors until you really need them, but it also brings in the danger of missing the point of encapsulation. For me, the point of encapsulation isn't really about hiding the data, but in hiding design decisions, particularly in areas where those decisions may have to change. The internal data representation is one example of this, but not the only one and not always the best one"