Inheritance and performance

[JV]

We have arrived at the class design shown below(slightly simplified for purposes of this question) for people in a company, where:

1. Person is the base for all people types
2. A HeadcountPerson is a person who is deemed to be part of the company's  population. We also have NonHeadcount people who are not part of a the company's population.
3. Headcount people include Employees and Contractors
4. An Assignee is a type of Employee

From a design viewpoint the inheritance seems to work well for the following reasons I can think of, there are probably more:

1. It will allow us to treat all the different people types as the same Person type when necessary
2. We can use polymorphism to deal with behaviour that is common to all Person types but needs to be  
   handled slightly differently in each child class
3. Each child class only encapsualtes behaviour and properties which is applicable to itslef, which makes using the class clear and simple
4. code reuse.

However in the past we have run into performance problems with inheritance. We use a layered approach when coding thus each of the classes above will belong  to the business logic layer and each will have an associated data access class which will handle getting the data for each business logic layer class. This  means for example that when we instantiate an instance of the Assignee class, the code will be going to the database 4 seperate times and running 4 seperate  queries which results in a slow User response time especially when working with lists of objects.

I would appreciate any comments on the above design and in particular if there is a way to maintain the design without the performance problems



Thanks John

[thomaskilian]

A very broad question since it depends on many parameters (language, database, implementation details, type of database connection, network, OS, etc.). If you fear performance loss you are of course free to denormalize your database access layer. On the other hand this will bring in other problems... I'd not take this into account as long as you can scale your hardware, which is essentially cheaper than implementing faulty optimizations.

[Eve]

From looking at your diagram it looks as if each class is being represented as a table in your database.

The idea that jumps out to me would be having an overridden method in each class to construct the SQL needed to fill it, where each one is a query on its own table joined with the SQL for its parent class.  The constructed SQL is run and the class fields can be filled in a similar fashion.

Of course, this is a potential "faulty optimization" so heed the previous warning.

[Paolo F Cantoni]

Hi John,

How fast do you want the wrong answer?

Heed the Agile aphorism:  "Make it work, make it Right, make it Fast."

Or as a colleague of mine put it:  "You can never second guess performance".

Make it Fast is LAST!

You first need to determine if the model will support the facts you intend to hold.

For example, inheritance hierarchies are predicated on the descendants being disjoint.  If they aren't; then you have a lattice, not a hierarchy.

For example, could the same person for the same period of time be both an Employee and Contractor?  (I have been!).

What I think you'll find is that the subordinate subtypes are actually Roles.  For each role there has to be an (is_a - which isn't a Generalization) that the object in the Role is (that should be represented by a special type of Association) and another thing with respect to which the Role is undertaken - for example in your case, the role of Employee is undertaken with respect to a Business Entity.  If that Business Entity is "US" then it is our employee.  If the Business Entity is not "us" then it's some-other's Employee.  You get the picture, I hope.

So before we get to the technicalities of the persistence.  Confirm your model can hold the facts that it needs to hold.

In my view, I modify the Agile aphorism slightly:  "Design it well, make it work, make it right, make it fast."  By "design it well", I mean do sufficient design to ensure you don't have an obvious design flaw.  The kind of fact-based bench testing of the model comes into that category.

HTH,
Paolo