On Sun, Mar 21, 2010 at 6:09 PM, Sean Corfield wrote: > On Sun, Mar 21, 2010 at 2:18 PM, denstar 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 :)
For them it's encapsulating the fields they access, right? Protecting "the rest" from changes to underlying data structure? They're all about encapsulating data access, right? >> 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. I know. :) /That/ was "the above line of reasoning"-- not what you said, but what someone might take away from hearing "avoid getters and setters". :)p ... > 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 love those pragmatic peeps! Excellent stuff! Mostly that was my one point, such that it was-- "tell, don't ask" is a lot more useful than saying "avoid getters and setters, especially private ones". And maybe that [g|s]etters are a valid pattern for encapsulating some stuff, some times. And to not have you having gone to the trouble of donning a flame-suit for nothing. >> 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 :) Damn you! How can I dispute this one... hrm... ah well. Obviously my whole argument against your rule of thumb is pretty weak, so maybe I could just call you names at this point? Blaggard! >> 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. Hey, I'm telling the thing to set it's first name! Maybe it's a validator-type whatnot. heh. And encapsulation is a multi-level, multi-pass (as you say) deal. Take the svn tag I wrote. I could have done _intance.repository, but I was pretty sure I'd need to do more than that, so I did getRepository() at the outset. Functions are a tired and true method of encapsulation (even if they're ones that are procedural in nature). Objects have procedure (or behavior, if you will), or else you'd never be able to model flow and interaction. There's probably always some kind of mix of procedure and action. Or action and procedure, maybe. Um, yeah. Well, I'll stand by my previous assertion that an IDE with awesome refactoring support makes a lot of this not as hard to change as it otherwise might be. Which is part of why I'm working on CFE. Scary, right? :) :DeN -- Eyes and ears are poor witnesses to people if they have uncultured souls. 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.
