Why was this considered OT?? One way YAGNI applies in this kind of situation is that the stories asking for visible business functionality should be separate from the stories asking for persistance functionality. Given the dependencies between those stories, the business functionality stories almost always have greater business value to the customer than the persistance stories.
Persistance is totally YAGNI when implementing the business functionality stories, so you first end up with a Customer class that provides the visible functionality your customer needs (via iterative feedback) with tests that verify its behavior. Then, when the persistance stories are the highest priority stories not yet implemented, persistance is no longer YAGNI. DoSimpleThings, ExpressiveCode, SingleResponsibilityPrinciple, etc. will then lead to building a data access layer (or leveraging an existing framework). Refactoring (i.e., continuously applying OnceAndOnlyOnce) will keep it as simple as possible. If the original question was whether having virtually identical field names in the Customer object, the database, and the data access layer mediating them constitutes duplication, that appears to me to be a form of duplication whose elimination would likely lead to code that is far more difficult to understand and maintain than the code with the duplicative field names. Consider CMP in J2EE which is essentially driven by meta-data expressed in XML files. I have found CMP frustrating because I cannot refactor the code (or the database) without carefully editing that XML file. It does not feel like OnceAndOnlyOnce when I have to keep the database, code, and XML descriptors in synch. Of course, an Eclipse Plugin with XDOCLET-like functionality could automate a lot of the synchronization issues away. Steven A. Gordon, Ph.D. Manager, Software Factory Arizona State University PO Box 875506 Tempe, AZ 85287-9509 http://sf.asu.edu (480)-727-6271 -----Original Message----- From: Ramon Leon [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 11:29 AM To: [EMAIL PROTECTED] Subject: RE: [XP] [OT] Delegation and YAGNI! YouArentGonnaNeedIt is only one of many principles, you have to balance it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to making sure each class only has one responsibility, and you are gonna need that. YouArentGonnaNeedIt is not a justification to violate basic good OO principles like SingleResponsibilityPrinciple. In the java community, I'm pretty sure most people just use existing open source object mapping layers, in the .NET world, most are still hacking up their own private implementation because there isn't any really outstanding open source implementations yet. > -----Original Message----- > From: Stede Troisi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 9:53 AM > To: [EMAIL PROTECTED] > Subject: [XP] [OT] Delegation and YAGNI! > > > I was thinking about YAGNI yesterday. Normally, I see most > people create a customer class that holds domain information > and another class, say CustomerDb that persists the > information from customer to a database. > This makes sense, becuase if I want to persist to something > different (like a flat file) I can create a new class to > handle it while leaving the domain class intact. > > But two objects that share the same basic fields > (customer) seems to go against YAGNI. Is this how most people > solve the problem or is there a better solution? > > Thanks, > Stede > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > > > To Post a message, send it to: [EMAIL PROTECTED] > > To Unsubscribe, send a blank message to: > [EMAIL PROTECTED] > > ad-free courtesy of objectmentor.com > Yahoo! Groups Links > > > > > > > > To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
