Re: What databases have taught me

frebe73_at_gmail.com wrote:

>>- I started life as a procedural programmer.
>>- I adopted OO and soon got the 'aha' click described by R. Martin.
>>- I spent years coding large OO projects, with beautiful, elegant
>>architectures.
>>- I spent further years practically gnawing my arm off attempting to
>>adapt my perfect OO designs as requirements inevitably shifted and
>>exceptions arose.
>>- I finally realised that my 'aha' was utterly illusionary, and that my
>>code, being OO, was inevitably and irrecovably imprisoned in a
>>hierarchical strait-jacket

Indeed.

> After all OO started in the telecom industry and I think that OO showed
> some significant benefits in that area. But the big problem is then the
> gurus tried to apply OO everywhere, specially in business software for
> accunting, logistics, HR management etc.

Are OO programs much worse than procedural or functional ones in this domain ? 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 ?

> I think that the main disadvantage with OO is that it is not
> multi-dimensional. OO textbooks like to use animals as an example.

Alas...

> They
> like to build a polyphormic hierarchy like this:
> Fish
> - Shark
> - Tunar
> Bird
> - Eagle
> - Condor
> Mammal
> - Horse
> - Dolphin
> - Bat
> This is the correct zooligical hierachy.

Yes, and a very bad example of the use of subtyping in OO. Also, it somehow relies on the assumption that polymorphism is conditionned by class inheritance - which, while somehow the case with languages like Java, is not necessarily true for all OOPLs.

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

class Swimmer(Animal):
  def swim(self):
    pass

class Shark(Fish, Swimmer):
  pass

class Dolphin(Mammal, Swimmer):
  pass

FWIW, note that I used a Swimmer class only to factor out common behavior. I could as well write it like this:

class Shark(object):
  def swim(self):
    pass

class Dolphin(object):
  def swim(self):
    pass

And BTW I would certainly start this way unless I already know factoring out common behaviours will makes sens for the problem at hand.

> 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 !-)

Trying to fit entities as revealed by a first analysis of the domain into a straight, uni-dimensional hierarchy will certainly lead to a very bad design. Problem-domain entities and solution-space abstractions are not necessarily mapping 1:1.

My 2 cents

-- 
bruno desthuilliers
python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"