> There's a step or two > between understanding how your person class holds common behavior for > its descendent student and teacher classes
What if they're a student teacher, then you need a studentteacher class as well. Ick. ; ) > You could very well code CRUD and search methods directly into your > objects. I do this, on occasion, though I usually put the SQL in the service object not the bean. Lot faster to develop, and for things that are utterly simple, there's no reason to build the full-on OO backend up front. As long as you've got your API in place, you can always reimplement what's behind it without affecting anything else. And that's really the power of an OO system, in my mind. The facilities for abstracting the interface and implementation are so utterly fundemental to efficient application development, that anyone who ignores must be a glutton for pain. Don't take that to mean I think OO is the only way to get that, that's a false statement, but OO is the way I'm most comfortable with and which makes the most sense to me. cheers, barneyb On 8/22/05, RADEMAKERS Tanguy <[EMAIL PROTECTED]> wrote: > >Cool! That's the way most patterns start - they're not really cooked > >up, they're just things developers started doing, then said to each > >other "Hey! I do that too! Let's call it something so that we can > >share the technique." > > Even more than that, patterns are standardized solutions to common > problems. And the patterns we are discussing here (gateways, DAOs and so > forth) are solutions to a rather specific bunch of problems you > encounter when you have objects that need to be > stored/retrieved/searched for in/from a database. This may seem obvious > to some but i think there are a lot of people out there who confuse > object orientation with design patterns, and either go straight to the > design patterns books or else move a little quickly between introductory > texts in OO to advanced texts in design patterns. There's a step or two > between understanding how your person class holds common behavior for > its descendent student and teacher classes and understanding why it's > best to use a factory object to produce table data gateways so that you > can avoid unnecessary instantiation and inject configuration info at > object creation. > > You could very well code CRUD and search methods directly into your > objects. I can hear the hackles rising from here, but hear me out. I > understand that it's not a good idea to have a single model for the > domain and the implementation of an application. I am more than willing > to stipulate that the time you gain in the first place by writing fewer > classes will eventually be lost if and when you want to reuse one of > your objects in another application or, even worse, deploy your > application with a completely different data storage system like xml > files in stead of a database. But the benefits are that a) you're still > better off than if you decided to just have some free floating sql in a > .cfm page and create objects from the results, b) your object model will > be much easier for *you* to understand, especially if you are starting > out (as you'll be closer to the domain model of your app) and - this is > the big one - c) you will eventually run into those aforementioned > problems with storing (and etc.) objects in a database. And you will > have to put in gateways, and DAOs, and all that stuff. And you will have > to rip out all that CRUD and search code that lives in all those > different objects. And you will suffer. Especially since you didn't > write unit tests. But by then you'll understand it, and you'll build > that way from then on out. In fact, the objects you write for accessing > data in the database will most probably become some of he most reused > tools in your kit. > > I'm sure that not everyone will agree with me ;) > > Fred Brooks wrote "plan to throw one away - you will anyways". Granted, > that's not the easiest thing to sell in a work for hire environment. But > if you try to jump straight in at the deep end with too little > understanding, you'll wind up not just throwing one away but deciding > that "object orientation sucks" and never looking back. And that would > be a pity. > > /t > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
