|Keep It Simple, Stupid|
OO design and persistenceby jimbus (Friar)
|on Dec 22, 2005 at 15:02 UTC||Need Help??|
jimbus has asked for the
wisdom of the Perl Monks concerning the following question:
I've started reading a book on object oriented design and I started thinking ahead a bit and have a question on object persistence.
The current discussion is about inheritence and its using the example of people objects having certain attributes and behaviors and then certain subgroups of people (say, teacher or student) have specialized attributes and behaviors on top of those they inherit as being people. So even though I'm in chapter one and we are just talking in abstraction, my mind moves off toward how I might implement some of this in code... specifically how would I handle persistence.
If I implement an person object, with all its attributes and methods, I would persist it as a table with colums for each of the attributes and methods for accessing them and performing its actions. If I then create a student object that ISA person, do I create a new table that has all of the person and student attributes or do I have two tables, one for inherited data and one with new data and join on an object id? Or am I confusing layers here... persistence should be kept separate from behavior and attributes or maintained on the lowest level of inheritence to avoid confusion?
As a extension: from a DB perspective, if a chuck of info is someting that you would logically normalize into its own table, does that suggest that it should be its own object?
Never moon a werewolf!