Re: What databases have taught me

From: <frebe73_at_gmail.com>
Date: 23 Jun 2006 11:29:40 -0700
Message-ID: <1151087380.243768.41240_at_i40g2000cwc.googlegroups.com>


> So, is it a problem with OO, or a problem with how OO is used ?

Both.

> Yes, and a very bad example of the use of subtyping in OO.

In fact, subtyping have to be used extremly carefully if you don't want to mess things up. It is a very inflexible tool.

> > But what if there are features
> > (or behavior) that are common for all animals that can fly or that
> > lives in water?
> What's your problem here exactly ?

The implementation might depend on multiple dimensions.

In a recent thread Robert Martin suggested a similar class hierachy: Employee

- Salaried employee
- Hourly employee
- Commissioned employee

The Employee interface should have a calculatePayment method and the subclasses should have different implementations.

This might look like a natural thing to do and it probably is while the problem solution is small and not very complex. But imagine that depending on what union branch the employee belongs too, the salary is calculated differently in some aspectes. Now you have to repeat this logic in all three implementations of calculatePayment. This is one example of problem you will encounter when you start with on dimension and later have to handle multiple dimensions.

> > Many business entities like bank accounts and employee
> > types, are almost impossible to classify in hierachies.
> Indeed - business rules are usually much less logical and 'universal'
> than scientific taxonomies !-)

Is it not about being logical or not, it is about being able to handle multiple dimensions or not. (But I agree that many business rules are unnecessary complex.)

Fredrik Bertilsson
http://frebe.php0h.com Received on Fri Jun 23 2006 - 20:29:40 CEST

Original text of this message