Re: What databases have taught me
Date: Sat, 24 Jun 2006 14:51:27 +0200
>>So, is it a problem with OO, or a problem with how OO is used ?
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.
> In a recent thread Robert Martin suggested a similar class hierachy:
> - 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