On 5/17/06, Steve Brownlee <[EMAIL PROTECTED]> wrote: > 1. Validation
That's fine for atomic validation (specific validation rules for this particular field) but you'll still need a way to validate the state of the entire object -- relationships and dependencies between attributes. And since you're going to validate the object later in your scenario, why make it harder by putting validation in each setter and an overal method? All of the code you suggested to handle validation errors in individual setters is simplified by putting it all in a single validate method. PotatO, PotAto I guess ;) > 2. Encapsulation This is just plain wrong. What exactly are you encapsulating? You're actually _exposing_ more about the object (such as the specific get/set data types) that will make it *harder* to change your implementation. See this reference for example for a classic "why accessors are bad" discussion. http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html > 3. It just makes so much darned sense, don't it? No, it doesn't in a lot of cases. Especially in a weakly-typed language like ColdFusion or for objects that simply wrap a single database table. Not to pound directly on Steve since this slavish devotion to the DAO pattern comes up every time someone asks about basic db-oriented OO on the list. The DAO pattern is one of _many_ ways to model data objects. There's a whole lot more, some of these http://martinfowler.com/eaaCatalog/ for example. The DAO pattern for J2EE can be seen here http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html is all that _really_ necessary in this instance? Nothing so far points to that. OO is about more than DAO, beans, and getter/setters. In the Java world, you are almost always using a ORM like Hibernate or some JDO tool (or annotations in Java 5) to handle the infrastructure of the objects and the mapping to the database so you can focus on how the objects work together instead of writing lots of fairly tedious code. I think that in this specific instance, an ActiveRecord pattern makes far more sense. I'd suggest grabbing Joe Rinehart's Arf! and using it to handle the _very_ simple objects involved in this scenario as a starting point. Remember the goal is to create the objects in your software model that capture the essence of the object, it's behavior, and relationships. ActiveRecord is a great way to handle CRUD for an object that maps directly to a database table. But change the context and the approach changes -- need to count how many of the 10k rows of the table were put in service after a certain date? Slavish devotion to the DAO pattern gives you an collection (eg array) or 10,000 individual objects and an iterator.... that you iterate over with individual date comparions for each object.... Looking at the situation and the context you might choose the RecordSet pattern. Or the Query pattern and solve the problem in a much cleaner way. I'd recommend HF Design Patterns as well to get a good starting point on the whole patterns thing. And Thinking in Patterns. And your choice of a UML book. But as Dave Watts mentioned, the fundamental modeling process is similar to database modeling with the big addition of _behavior_, unless we're only talking about beans in which case it's pretty much identical. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:240836 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
