Dave,
I'd
keep in mind that you can look at a model thru different perspectives. A pure
conceptual model that would compose arrays of objects within arrays of objects
isn't often the best one to implement. I'd only take that route if i really
needed to manupulate the data in EACH of those objects in the array in a single
(probably editing) process. Otherwise i'm probably just wasting my time, the
client's money, and the server's resources building and persisting complex
objects.
From
an implementation perspective, i would ask myself, "what exactly does the app
need to accomplish in this moment?" and model that. It helps to look at mockups
of the app screen by screen and ask yourself that question in each
case. I've sometimes found that in looking at a model from an
implementation perspective, objects show up that, ones you
practically need, that don't fit in the pure conceptual
model.
If
you build out your model conceptually, then come back and try to wire it up, you
may find that things don't work out very well.
So
i'd sketch out both, just simply on paper, conceptual and
implementation step back and look at the app thru both perspectives,
conceptual, and implementation, and decide what you're going to do from there.
Perhaps instead of storing an array of company objects an application
scoped object, you'll see from an implementation perspective that there's no
need. (Maybe all you need is a query with the company id's and name to populate
a dropdown, for instance.)
I
think it's hard in the beginning to know where to draw the line, but after doing
this awhile, i'm giving a lot more weight to the implementation perspective, and
less to the conceptual, and i'm happy with how things come out that
way.
Hope
that helps a little ...
---------------------------------------------------------------Original Message-----I am refactoring an old procedural loan origination application system and am going through the process of UML design, and mapping out the relationships of all of my objects. I am still somewhat new to OOP, but I have built several small OO projects now and feel pretty comfortable with OO concepts such as composition vs. inheritance, and have built several small OO apps. I have yet to build a really robust fully OO system. I am running into a stumbling block in my train of thought in a couple of areas and wanted to get some opinions.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Dave Shuck
Sent: Monday, January 02, 2006 6:08 PM
To: [email protected]
Subject: [CFCDev] OO design question
Consider the following relationship....
A Company has Users (there are multiple companies)
Users (could) have Loan Applications
Loan Applications (could) have a plethora of their own properties of simple values and objects
I am considering building an application-scoped array of Company objects, each with a property of Users which is a structure of all users tied to that particular company, where each item (instance of a User object) would have its own properties/methods unique to that user. I have tested that in a small scale (adding/removing users) and it seems to behave like I would expect, so that part makes sense to me so far, but if you see any big things I am missing there don't hold back.
Now, my immediate concern is as follows: In listening to the Helms An Peters "Objects for maintainable code", I noted that Hal makes the comment along the lines that if we had perfect systems that could hold the objects forever, we really wouldn't need databases to persist the objects. If I understand that correctly, he is suggesting that all objects are loaded up when the application starts and the only database interaction is when persisting them. Am I understanding this properly? My gut feel (which is only slightly more than occasionally right) is that it seems unreasonable from a memory standpoint to hold every user in every companies' Users property(ies), and the properties/methods of each user within that, and the properties/methods within those, and so on to the end of the relationship tree. What is the best approach here, keeping in mind that I want to limit the database interaction as much as I can.
I really hate airing my ignorance publicly, but I appreciate any input on this scenario. :)
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com ----------------------------------------------------------
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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
