The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Persisting inheritance hierarchy

I'm trying to write my own ORM framework and I'm having difficulties to handle inheritance hierarchies.
Now, before you suggest to use a commercial tool, I want first to try and build it myself. This way I can see the problems and understand why commercial tools have done some choices.
Let's say we have a Person class and Organization class. Organization inherits from Person.
In the database there are two tables PERSONS & ORGANIZATIONS. Tbey have one to one relation so an organization has a row in each table.
The Person class has the logic to load & persist itself in database. The Organization class also.
To keep track of all loaded entites there's a Session manager that commits the changes in the right order.
The problem I have is how to organize the code in the Organization class. For the persist method I have something like:

if(deleted)
{
// persist itself
// persist parent
}
else
{
// persist parent
// persis itself
}

I don't like this code because the session manager is already doing this. But in the case of inheritance I have only an Organization object and no explicit Person object..
Should the Organization class have a member of type Person so the session manager has two instances and automatically  persist them in correct order?

I think I'm a bit confused, but any idea is appreciated.

Thanx
Albert Send private email
Tuesday, September 04, 2007
 
 
Canonical answer: An "Organization" is not a "Person", therefore there is no "is-a" relationship, and therefore you should not use inheritance here.

An "Organization" consists-of "Persons" -- which is a "has-a" relationship.  Therefore your "Organization" should have a "Persons" collection (or whatever) of people who "belong" to it as a data_member of the "Organization".

The fact that you have a SEPARATE "Organization" table, and "Person" table, shows that you recognize this already.  You just don't know that Inheritance is the wrong mechanism to use in this circumstance.
AllanL5
Tuesday, September 04, 2007
 
 
Maybe the example it's not so clear but I have inheritance in this case. Person is the base class and Individual and Organization are inherited. So a Person can be an individual or an organization.
You can forget the example if u want...just think of an inheritance hierarchy in general...
Albert Send private email
Tuesday, September 04, 2007
 
 
Yes.  The reason I personally use inheritance hierarchy's is if I'm using polymorphism to simplify or organize my code.

Since I can't imagine a set of code I'd pass a 'generic' Person object to, doing Organization or Individual things to it (depending on what it's real super-class was), I have a hard time extending such an example.

The problem with doing an ORM mapping with this structure is that the "Organization" contains "Persons" (I assume).  Thus when you 'save' the "Organization", it's supposed to 'save' the Person's in the organization?

Also, personally, I'd have a "parent" object make the calls to save its "children", and not the other way around.
AllanL5
Tuesday, September 04, 2007
 
 
In my example there are cases when I pass a Person object.
And there are other cases when inheritance is needed...so my question is more how do you treat cases when you have an inheritance hierarchy?

Thanx
Albert Send private email
Tuesday, September 04, 2007
 
 
How is an organization a person?
AmerrickanGirl
Tuesday, September 04, 2007
 
 
Naming is not good...I agree...
Let's change the example to a Transaction class from which InputTransaction and OutputTransaction are inherited...
Albert Send private email
Tuesday, September 04, 2007
 
 
How is an organization a person?

In the way a company pays income tax or has the "free speech" right to contribute to political candidates. Maybe think of it as "legal entity" and go on with the problem ...

Are you aware of the basic choices in storing a class hierarchy?

1) Make a table for each class, store exactly the fields of each class. So to save an Organization you write inherited Person fields to Person, Organization fields to Organization.

2) Make a table for each concrete or leaf class with all its fields, inherited or not. Store Organization in Organization, store Human in Human. The two tables both have Person fields.

3) Make one table with all fields for all classes in the tree, leave nulls for whatever doesn't apply. Save an Organization in the Person table with the Human fields null, save a Human with the Organization fields null.

Which of these do you want to use?
Stan James Send private email
Tuesday, September 04, 2007
 
 
Ok, I had to go back to see this: "In the database there are two tables PERSONS & ORGANIZATIONS." Are you thoroughly married to that design?
Stan James Send private email
Tuesday, September 04, 2007
 
 
I'm aware of the choices and I'm using the first one.

Thanx
Albert Send private email
Tuesday, September 04, 2007
 
 
I like more that design with two tables...I don't think it matters much..
Albert Send private email
Tuesday, September 04, 2007
 
 
There are 3 ways to map inheritance to relational:

1) Superclass table and related subclass tables (one to one).
2) One table per subclass (queries on the base class are implemented with union).
3) One table for all, having a type column.

Each approach has its advantages and disadvantages, depending on the problem they need to solve. Typically and ORM tool has a mapping which instructs the code which way the mapping has been implemented by the coder.
Dino Send private email
Wednesday, September 05, 2007
 
 
==>How is an organization a person?

Ignore that. It's not important to the OP's problem.

**

In an attempt to answer the above -- maybe it's just a poor choice of naming. I regularly run into the pattern of having Customers, where the Customer can be an Individual (Joe Blow) or the Customer can be a Business (Organization?)(Acme Inc.) and the attributes of each (In dividual or Organization) are slightly different -- for instance an Individual record may have FirstName MiddleName LastName, but a Business just has BusinessName. An Individual may have Mr. Ms. Mrs. prepended to their name but this doesn't make sense for a Business. A person may have a SSN, but the Business has, say, a TaxID.

The generic case is the Customer entity, and both Individual and Business inherit from the Customer entity.

I run into this one a lot. I think the OP's in the same situation, he's just using a poor choice for naming these entities that's causing all the confusion.
Sgt.Sausage
Thursday, September 06, 2007
 
 
Right Sgt.Sausage would be better with the names you suggested.
However, my point is how do I treat a inheritance hierarchy in general? Still have no solution for this...
Albert Send private email
Thursday, September 13, 2007
 
 
The problem is that you are trying to generalize and adopt a clean solution over a bad design..
"Organization" should not inherit from "Person". This is bad design.

If you want to adopt inheritance, there should be an abstract class "Subject" from which you derive both "Person" and "Organization"..

By doing this, you avoid the problem of not having a "Person" for a given "Organization". So you can adopt one of 3 solutions that have been previously explained: the superclass is "Subject" and the subclasses are "Person" and "Organization".

The same goes with Sgt.Sausage's example: superclass is "Customer" and subclasses are "Individual" or "Business" - but there is no inheritance relationship between "Individual" and "Business".

If you keep the class hierarchy, there are no clean solutions. Only dirty solutions will do.
Johncharles Send private email
Monday, September 17, 2007
 
 
video slots Send private email
Sunday, September 30, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz