Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: What databases have taught me

Re: What databases have taught me

From: Bruno Desthuilliers <onurb_at_xiludom.gro>
Date: Fri, 23 Jun 2006 12:25:33 +0200
Message-ID: <449bc19e$0$1683$626a54ce@news.free.fr>


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

>
>
> I share the same experience too. Its a very unpleasant exerience to
> finally realize that what you believed in for many years is just an
> illusion. But I still think that there are some limited areas, such as
> building collection classes (maps, lists, etc), embedded software or
> GUI components, in which OO have some benefits.

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 '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Fri Jun 23 2006 - 05:25:33 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US