Re: What databases have taught me

> >>So, is it a problem with OO, or a problem with how OO is used ?
>> Both.
> Could you elaborate ?

The main problem in OO enterprise applications is the desire to decouple SQL statements. This causes code bloats. Bloated code are harder to maintain. Another disadvantage is the fact that the number SQL statements should be limited and the the same statement should be reused in different contexts. This does not only creates problem writing the code, it causes performance problems. The fact that the result from the SQL query has to be mapped to a "domain object" also introduces numerous problems.

> >>>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.
> And ?

See the discussion about employee types.

> > In a recent thread Robert Martin suggested a similar class hierachy:
> > Employee
> > - Salaried employee
> > - Hourly employee
> > - Commissioned employee
> Hard to tell without the full context, but I would probably go for a
> single employee class and a strategy pattern for payment mode instead.

Subtyping payment modes instead of employee types has the same disadvantages. The key is to limit the use of subtyping.

> > 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.
> One more reason to switch to a strategy pattern.

The original solution used a strategy pattern too. The problem with the strategy pattern (and subtyping) is that you only have one dimension of strategies. Multiple dimensions (employement type and union association) might affect how the strategy should be implemented.

> > Now you have to repeat this
> > logic in all three implementations of calculatePayment.
> Having to repeat something is most often a design smell.

That's why a design using subtypes can be very dangerous.

> >This is one
> > example of problem you will encounter when you start with on dimension
> > and later have to handle multiple dimensions.
> This is one example of problem you encounter when you try to map the
> 10000-feets analysis view directly to implementation, totally skipping
> the design phase.

It seem to be very difficult to get i right using OO.... Maybe that is why we need the mentors...

> Now if you really think you can't handle "multiple dimensions" in OO,

Almost every language (OO or not) can handle multiple dimensions, but a subtype hiearchy can not.

Fredrik Bertilsson
http://frebe.php0h.com Received on Sat Jun 24 2006 - 18:08:24 CEST