I'm a database guy first, so that colors my perspective.
Designing a set of classes has a lot in common with database design. In On Flyweights... (with sneaky segue to data modeling), I visited the general area. In essence, I'm advocating applying normalization techniques to object modeling. The more you can minimize data duplication, the better. If you find, subsequently, that you have genuine performance issues that you can pin on that donkey, then (and only then) should you "denormalize". The biggest hurdle is modeling inheritance. I'd say to start by keeping the attributes for each class in their own tables. Child classes would need to keep a reference to the parent instance that contains the parent class data, and a parent class would need some way to distinguish data for an object *of* that parent class from data for an object in a subclass. From there, you can play refactoring games to move fields around, etc.
In reply to Re: OO design and persistence
by herveus
in thread OO design and persistence
by jimbus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |