>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 ---------------------------------------------------------- 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]
