Re: [CFCDev] OO Domain Modeling

[Nando]

Hey Jeff, The user interface and the architecture of an OO application driving it are 2 completely separate things. When you read introductory texts about OO, they can seem more connected then they wind up to be once an application is finished. For instance, you might have a User object behind a form that adds/edits a user. But that does not mean that you'll need to create Manager and Worker objects just because a User is-a Manager or a User is-a Worker. In fact, you might not even need a Role object. If your roles are pretty much predefined, you might be just fine having Role just be a property of User. In other words, if your application doesn't do anything with Roles (add, edit, delete) ... you don't need to model it. For me, that was the first thing i had to get. Not everything you can point at in your UI design as a noun becomes an object in your model. The second thing i needed to understand is that relationships between objects, all the Has-A Is-A stuff, inheritance and composition, only really come into play when that relationship is actively present in your app. For instance, if Users have Roles AND you are editing Users and Roles simultaneously in your app, (you can add a user and add a role in the same screen if the role isn't already present in the dropdown and prioritize each role added as a main or secondary role), then you might have a good case for using composition there. In other words, you'd instantiate User and inside of User you instantiate an array of Role objects or pass an instance of Role into user. Then you'd do the same with your UserDAO and RoleDAO when persisting the whole thing. You'd have a corresponding array of RoleDAO's composed inside of UserDAO. BUT, if you edit Roles separately, and don't have to set any specific role attributes when editing a User, then you don't need to compose Role inside of User, even tho' your Users have Roles. You can simply instantiate a simple Role object when editing Roles, and instantiate a simple User object when editing Users, and just use a RoleGateway to populate your role dropdown in your User form. What i'm trying to say is that entirely different criteria drive the design of an OO architecture than the relationships you might conjecture from the UI. Taking it to the next level, if you're thinking that one day you might put a Flex front-end on this application, then the first thing you need work out is your service layer. So instead of your controller calling UserDAO directly, your controller would call a UserService, and UserService might have a persist() method in it that takes care of delegating all the steps needed to persist a user to the different objects involved. That way, your Flex application can also simply call UserService to do the same. Another thing - Factories are an important element of any OO application. A factory's job is to create objects. You don't want createObject() function calls spread throughout your code. Just take my word on this. You want them only in objects whose job it is to create instances of your objects. Some people are using coldspring for that in certain circumstances ... this is another issue to get straight, but for now, you'll have a much cleaner and more maintainable app if you use a Factory or several to instantiate your objects. One more ... you can get a lot out of your OO design by persisting some objects and using composition. For instance, the obvious thing to start with is your Factory. On app start, you can instantiate your factory into application scope and use it from then on: <cfif NOT StructKeyExists(application,"Factory")>     <cflock name="factoryLock" Timeout="10" THROWONTIMEOUT="No" Type="Exclusive">         <cfif NOT StructKeyExists(application,"Factory")>             <cfset application.Factory = CreateObject('component','path.to.Factory').init(applicationSettingsofSomeSort, maybe via XML)>         </cfif>     </cflock> </cfif> Then anywhere in your app you need to create an object: <cfset myObjInstance = application.Factory.getMyObj() /> Or you can also get your settings object, which you've instantiated and cached in the variables scope of Factory ... <cfset myDSN = application.Factory.getMySettings().getDSN() /> soo .,.. as you can see, Factory can return new instances of objects, or cached instances of objects, or data from within pre-instantiated cached instances of objects. hope that gives a little window into the process ... i know everyone probably does it all differently, but these are some of the considerations i take into account when designing an OO model, and i'm not even that good at it yet. ciao, Nando Jeff D. Chastain wrote: A philosophical question for a Friday afternoon .... I have done plenty of projects in the past using Fusebox and other frameworks with the FLiP design process.  For those not aware of FLiP, basically you design out the entire UI of the application before any backend coding is done.  Then, you break each page up into individual pieces (display fuses) and determine what logic and backend code is necessary to support that display code. Now I am looking at developing a fairly large application and there are many things about it that seem to say it would be a better fit for an OO type design.  So, my question is how do you start to model an OO application?   Do you just jump in and start creating objects (sounds like a bad idea), or what? Thanks -- Jeff -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com