The "delay-loading" notion can allow the same "heavy" class to behave in "lightweight" fashion.
If the info about employee info/history, course/session info, etc are provided in "contained" objects of the Person, those objects can be NULL unless/until the info is requested. If the info is never requested, you have a pretty lightweight Person object. If the info represented by the initially-NULL object is requested, the object is created and the relevant database info is read. In cases where there are multiple tables involved in representing the data (e.g. if employee history is stored in a different table than current employee status), the data from each involved table can be represented by a "contained" object that is only created, and populated from the database, upon request. Isn't software development interesting? At 09:57 AM 1/17/2006, Bill Bassler wrote >I was thinking for the puposes of "responsibility behaviours "delay-loaded" >was an approach to consider. > >Of course, having multiple Person implementations via interfaces works too. >The issues that might make this approach a bit complicated for my purposes >are that essentially there are many helper functions that are used to query >and filter collections of Persons for different purposes. For example, the >purpose might be just to fill a list with names or the purpose might >require that quite a large nesting of collections (and all of the database >connections that are required to fill them; which can effect performance >for a relatively small collection). For example, a list of Persons >containing objects that define student courses and related session >information. > >Some typical requirements for what needs to be included in the Person and >what needs to be included in the collections are: > >Get me every Person with the Last name of 'Jones' to include name only. > >Get me all Person(s) that are a "Counselor" or a "Teacher" to included >employee information, history etc. > >Get me all Person(s) that are a "Student" to include course and session >information. > >Get me all Person(s) that are a "Student" with the Last name of 'Jones' to >include course and session information. > >So, different types implementing an interface might get a bit tricky as far >as knowing what casts to make when the various Persons implementaions are >returned. I just wondering if another approach might be to have the helper >functions request that certain responsiblity/functionality is added for >returned Persons. For example, get me every Person with the Last name >of 'Jones' for display only. This would just return Persons instantiated >with basic identifying info only and would not incur all the overhead >unless required for the purpose. > >You could get a similar behavior with interfaces to if they were defined in >the appropriate way too. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
