On Sun, Mar 21, 2010 at 2:18 PM, denstar <[email protected]> wrote: > Hey, DAs are Objects too! ;)
DAOs are generally stateless singletons - so they don't have attributes you might be tempted to expose via getters :) > 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? No, I didn't say that. Setting (or getting) raw data attributes on an object, by any means, should be considered suspicious. What I said was that there are procedural areas of code (such as views) where readonly access to an object's attributes is useful, pragmatically (although it can still be avoided via a render()-style method). > 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. Not sure what "above line of reasoning" you're referring to but it's a good article and explains why you should tell your objects to do stuff instead of asking them for their data (attributes) so that you can do stuff with that data. Again, any use of setting (or getting) raw data attributes on an object should be considered suspicious since it violates the Tell, Don't Ask principle. > I'm not advocating to blindly add [g|s]etters, and I'm also not > advocating to blindly remove [g|s]etters. Since my code starts with no get/set methods, I only have to worry about adding them - very carefully, if the client code really needs them. There's nothing to remove in my code :) > 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. Ah, but the problem is you're trying to eliminate get/set and shift from ask to tell rather than approaching a closed (encapsulated) object and telling it to do something in the first place! If the default is no get/set and a mindset of telling objects to do stuff then you will occasionally make a deliberate shortcut of *adding* a getter (and very rarely a setter) in order to "get it out the door" - but that will be the unusual situation and a conscious choice to "do the wrong thing" and you'll create a ticket to refactor it in the future. > People should think carefully about how objects communicate, period. Yes. An exercise that I've found very valuable to help people 'get' OO is to sit them down in a circle and give each person responsibility for a single object. Then I ask them to get the job done by telling each other to perform some action that is within that object's capabilities. People seem to be much better at OO when you take them away from code and make them interact like that - because in the real world we don't generally ask for a bunch of data, perform some calculation and then give the result back to the person we got the data from... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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.
