I don't know about justifications. I do know that I have often wished that I could design objects in a database that were composite, and objects that were inherited.
The best example I have was the desire I had at once to design a system that would allow me to record important pieces of information for various pieces of hardware in an inventory system.
Monitors have a screen size, Hard drives have a disk space, various objects all have different things.
Rather than having to design an interface for each different type of hardware, or a form for each different type of hardware I want, I could create a "hardware" object, and have other types of objects be inherited from it. This would allow interfaces to either use detailed information about an existing hardware type (e.g. "monitor") in order to display it specifically, or use general information about the "hardware" type in order to display it generally.
There are other ways of doing that, of course, but it seems like OOD would help.
I think the primary justification for it, though, is that it would be of advantage for object oriented software to not have to map relational data to an object model when retrieving information from a database. It could, in fact, off-load the responsibility of keeping objects in memory to the database, and if the database was particularly well suited to the task, might speed up application time.
In all honestly, I'm talking out my ass, here, but these are the things that I seem to remember thinking about about 3 years ago when I looked at it first.
Into Canadian Politics?
[ Parent ]