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: Mon, 26 Jun 2006 20:18:12 +0200
Message-ID: <44a024e5$0$9590$636a55ce@news.free.fr>


frebe73_at_gmail.com wrote:

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

If you mean 'enterprise' la Java-PHB-buzzword, then the main problem is with believing in bullshit that silver-bullet dealers want to sell you.

> is the desire to
> decouple SQL statements.

To decouple them from what ? From the view code ? I wouldn't call this a problem.

> This causes code bloats. Bloated code are
> harder to maintain.

The problem with putting SQL statements everywhere in the code is that it causes duplications. And everyone should know why duplication is bad... Or do you advocate redundancy in the schema too ?-)

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

Does it "have to" ? I've seen a lot of ways to use OO in SQLDBMS-based applications, not all using "domain objects". So this can't count as a problem with OO itself, only with how OO is/can be used.

Also, and FWIW, using a dumb data-holder (dynamically created class, hashtable, tuple, whatever) or a more elaborate object is a design choice. Like all design choices, it has pros and cons. Like all design choices, it should IMHO be based on the contex. There's nothing like a 'one-size-fits-all' golden rule here. If using a more elaborate object solves more problems than it creates, and if the later are easy to solve, then it may be the right thing to do. Let's be pragmatic, will you ?

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

I still fail to see where's the problem.

>

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

Who talked about subtyping ? Is your reference OOPL so deficient that you cannot attach/replace methods on a per-object basis ? If so, bad OOPL, change OOPL.

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

Strategy pattern doesn't imply subtyping, cf above.

> is that you only have one dimension of
> strategies.

really ?

> Multiple dimensions (employement type and union
> association) might affect how the strategy should be implemented.

Then use multimethods and method combination. Or simply a template method FWIW...

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

cf above - and below too !-)

>>Having to repeat something is most often a design smell.

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

That's why a *bad* design using subclassing can be very dangerous. But a bad design is a bad design is a bad design...

(not to pretend I never do bad design...)

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

Who said design was easy ? And would it be easier with a strictly procedural approach ? Or with a strictly functional approach ? And in both cases, would it be easier because of the approach used, or because of the adequation between the problem, the way the designer thinks, and the approach used ?

FWIW, I've never been able to come up with a sensible procedural solution to any non-trivial problem. And yet I've seen some pretty good procedural solutions to non-trivial problems.

I'm afraid that the problem is more with silver-bullet dealers than with OO itself. If you (ie : a 'generic' you - not necessarily th person named Fredrik Bertilsson) believe that just using a braindead so-called "OO" language and following the braindead "OO 101" tutorials is enough to get any advantage from OO, then you're in deep deep trouble... And you can s/OO/whatever/g IMHO.

OO is just a way to organize code. If it don't fit your mental map and/or the problem to solve, use another way. There's no need sticking to the same approach for each and any part of a program (but using a language that let you mix approaches without too much inconsistency is of great help).

> Maybe that is
> why we need the mentors...

Hmm... I've always been suspicious of self proclaimed 'mentors'. My best 'mentors' so far have been newbies questionning some complex or complicated parts of my solutions !-)

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

Ever heard of duck typing, multiple inheritance and multimethods ? OO is not necessarily about inheritance and "subtype hierarchies" - that's something I unlearned when I switched away from PHB-oriented languages and crappy 00 tutorials.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Mon Jun 26 2006 - 13:18:12 CDT

Original text of this message

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