A performance issue in the context of user input? Are your users running 90mhz Pentium IIs?
I would think that you could use the world's fattest and slowest Person implementation in any kind of UI context and the performance would never be noticed, perhaps unless you're planning on creating an array of 100,000 of them. I would not worry about performance of anything that involves data in memory, until someone tells you that you need to because something is too slow. "Premature optimization is the root of all evil." (See my other post on Ghirish Jain's "structure vs object" thread.) A truly full-featured Person object should likely not have any simple types in it. For example, you would often need a collection of addresses, each with its own type (default, home, work, mailing, temporary between these dates, etc). Anything related to education potentially needs a hefty collection based on a complete set of related tables -- are you just keeping track of schools attended (with Harvard different from Harvard Law and Harvard Medical), or do you need degrees received, courses taken, etc? Even the concept of "person name" is likely to need some kind of collection -- if the person gets married, the name can change; a divorce might change it back (or even to a name we've never seen). Do you want to lose that history, and lose the ability to find the customer's order placed before she got married because all she remembers is what she bought (and not whether she was married -- and thus what her name is on the order -- before she bought it)? One way to handle this is to define an IPerson interface. Any object that satisfies the IPerson interface can then be used -- so you can implement SimplePerson : IPerson that has just the minimal stuff needed for the interface. You can add gobs of stuff to the IPerson interface, because it doesn't take up any space in simple objects that implement only subsets of the interface (and return empty strings or nulls for the stuff they don't have). Or, you can create IEducatedPerson and INameChangePerson (etc) interfaces and implement as many of those interfaces as you need/want in your SimplePerson / EducatedPerson / AllBellsAndWhistlesPerson classes. You can hide the "education" section of the screen if the IPerson object can't be cast as a non-null IEducatedPerson object, for example. I'm not sure what the pattern name for the "interface-oriented polymorphism" technique that I've (poorly) described. Good luck... At 11:08 AM 1/13/2006, Bill Bassler wrote >I'm looking for the best way to handle the situation where a particular >object represents a business entity is used for multiple purposes. > >For example: A Person object. >In some cases I need a object that contains a great amount of detail about >a Person; say, name info, address, education background and detailed >buisness-centric information. This object is typically used for detailed >buisness logic processing. I also have a need for the the same entity just >serve the purpose of filling a drop down list with a list of First Name, >Last name for a UI selection. > >In the first purpose I need a "full featured" object. In the second purpose >I do not. Also, performance is likely an issue here, as usual. > >Question: Is there an OO pattern or concept that addresses these types of >requirements for design? I see the following patterns as possiblities. >Opinions please. > >Builder pattern >Decorator pattern 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
