Re: What databases have taught me
Date: Mon, 26 Jun 2006 20:18:12 +0200
>>>>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
> is the desire to
> decouple SQL statements.
> This causes code bloats. Bloated code are
> harder to maintain.
> and the the same statement should be
> reused in different contexts. This does not only creates problem
> writing the code,
> The fact that the
> result from the SQL query has to
> be mapped to a "domain object" also
> introduces numerous problems.
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.
>>>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)
> is that you only have one dimension of
> 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 '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in 'onurb_at_xiludom.gro'.split('@')])"Received on Mon Jun 26 2006 - 20:18:12 CEST