Re: What databases have taught me

From: Bruno Desthuilliers <onurb_at_xiludom.gro>
Date: Sat, 24 Jun 2006 14:51:27 +0200
Message-ID: <449d3550$0$10282$> wrote:
>>So, is it a problem with OO, or a problem with how OO is used ?
> Both.

Could you elaborate ? For the record, here's the full context: """
My own experience is that I write better software and have less maintenance nightmares with how I use OO today than with some procedural programs I've had to work on - but then, I've also worked on very badly designed/written OO apps, and that was by no mean better than the badly designed/written procedural apps :-/

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

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

Indeed - or at least, subclassing is a very inflexible tool with declarative static typing. But this is not a problem with OO, it's a problem with trying to do OO with a somewhat deficient type system.

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

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

> The Employee interface should have a calculatePayment method and the
> subclasses should have different implementations.
> This might look like a natural thing to do

This hierarchy may makes sens during first analysis steps - but I certainly would try to get rid of it during design (now here again, we don't have enough context to make such assertions).

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

> Now you have to repeat this
> logic in all three implementations of calculatePayment.

Having to repeat something is most often a design smell.

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

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

"logicality" of the rules surely impact design IMHO. It's usually easiest to come with a sound design for even complex but stable and non-arbitrary rules than for mostly arbitrary and rapidly changing rules.

Now if you really think you can't handle "multiple dimensions" in OO, then it's perhaps more a problem with how you design your application than anything else (well, the language may also makes thing unnecessarily harder too... As a matter of fact, a good part of the canonical design patterns are mostly workaround the rigidity of declarative static typing)

> (But I agree that many business rules are
> unnecessary complex.)


bruno desthuilliers
python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Sat Jun 24 2006 - 14:51:27 CEST

Original text of this message