On Sun, Mar 21, 2010 at 12:49 PM, Sean Corfield wrote: > On Sun, Mar 14, 2010 at 5:40 AM, denstar wrote: >> I'd say a [g|s]etter could help with encapsulation, like say for with >> a DAO who's data field names change a lot (first_name, firstName, >> fname...). > > Straw man. The DAO should map the column name to the business object > attribute. Nothing to do with get/set on a bean.
Hey, DAs are Objects too! ;) I'm not really arguing that everything should have [s|g]etters, just that it is a way to "encapsulate change". Although "encapsulating change" is a loaded term... > And there are situations - at the boundary between the OO model and > the procedural rendering code - where *some* getters are necessary > (unless you have a rendering method on your object and pass it a > parameterized string to perform replacements on - or some such). So foo.blah (get or set-- hey, how do we know? By looking at context? == vs = ?) is "better" than foo.getBlah(), 90% of the time? Or foo.blahAndBar = heh, is better than foo.setBlahAndBar(heh)? Or should we just have "return this" vs. anything at all? :) http://www.pragprog.com/articles/tell-dont-ask says basically the same thing as the [g|s]etters are bad deal does, but avoids the above line of reasoning. I'm not advocating to blindly add [g|s]etters, and I'm also not advocating to blindly remove [g|s]etters. I'm just advocating the same thing you are, really-- think about what you're doing. But /don't think too much/! Doing mental acrobatics is swell for solving the problem, but if you're doing them just to try to follow "general" advice (I spent two hours on it, but now I don't have that setter/getter anymore! Does it really matter? I don't know, I just heard it was a Good Thing...), well... it's good practice but not very productive in the "get it out the door" sense. > The trouble is, if people start out from the position of > "encapsulation = add get/set for every property", they've already > completely broken encapsulation. If instead they start out from the > position of no get/set methods and only add them as external usage > seems to require them, they'll think more carefully about why they're > exposing the data. People should think carefully about how objects communicate, period. There are lots of exercises that can help with this (whiteboards, contracts, unit testing, etc.). Change is a wily beast... "thar she blows!". :DeN -- Corpses are more fit to be thrown out than is dung. Heraclitus -- You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en.
