Re: What databases have taught me
Date: 26 Jun 2006 13:01:49 -0700
> > 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.
I use the word "enterprise" just because I don't want anyone to get the impression that I am talking about FTP-clients, MP3-players etc here.
> > is the desire to
> > decouple SQL statements.
> To decouple them from what ? From the view code ? I wouldn't call this a
Decoupling from the rest of the application. You can find many successful applications like osCommerce that put SQL code in the view code (PHP) with great success.
> > 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 ?-)
If you have two identical SQL statements it is a good idea to put it into a function, unless it is more trivial than actually calling the function (like update customer set lastname=? where customerid=?). But if you put non-identical trivial SQL statements everywhere, you don't cause any duplication, only less bloated code.
> > Another disadvantage is the fact that the number
> > SQL statements should be limited
For example, a common practice is to only have one update method which updates all columns, regardless if they need to be updated or not. The same practice can be seen with select statments, all columns are selected regardless if you actually need the value or not. You have similar problems with joining.
> > and the the same statement should be
> > reused in different contexts. This does not only creates problem
> > writing the code,
The N+1 problem is well-known in EJB for example.
> > 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.
Another problem with OO. Nobody actually knows that OO is. Many OO evangelists would fight until they die before they drop the use of "domain objects". Maybe you can provide links to the definition of OO?
That is why I don't use OOAD.
> >>>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.
> > 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.
In this case Robert Martin. If you use a typeless language, subtyping is of course impossible. But some people seem to prefer typed languages.
It seem to me that subtyping is used. Maybe this is an issue about typeless vs types languages.
> And would it be easier with a strictly
> procedural approach ?
I don't know your definition of "strictly procedureal" but designing a relational data model is pretty easy anyway.
> 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.
> If it don't fit your mental map
> and/or the problem to solve, use another way.
That is what I am doing.
So far I know, multiple inheritance was skipped in Java because all the disadvantages.
http://frebe.php0h.com Received on Mon Jun 26 2006 - 22:01:49 CEST