On 7/8/07, Jaime Metcher <[EMAIL PROTECTED]> wrote:
OK, the lightbulb has gone on. I had assumed (wishful thinking?) that with the right OO constructs, the logical and physical models become so close that there is no strain flipping back and forth. In other words, I can use the physical implementation to prototype the logical model.
No, there's often a large gap between the logical and physical models. Consider aggregation relationships. In the logical model, all you know is that objects of class A have-many objects of class B but you don't care how it is implemented. In the physical model, you need an additional "class" to model the actual aggregation mechanism (even if it is as simple as an array or struct - although it may be a separate collection class). Furthermore, your logical model has no design patterns applied (in general). Design patterns are usually part of the process of mapping from logical to physical design, e.g., when you realize you need the Strategy pattern to reconcile several different parts of your logical model into something more coherent in your physical model. In particular, the various Factory patterns will never be part of your logical model - they are physical implementation artifacts, almost by definition. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
