Re: Mixing OO and DB
Date: Tue, 4 Mar 2008 12:01:56 -0800 (PST)
Message-ID: <99572246-3a05-4afe-ac57-a4c4003ab499_at_h11g2000prf.googlegroups.com>
On Mar 4, 10:10 am, Gene Wirchenko <ge..._at_ocis.net> wrote:
> Robert Martin <uncle..._at_objectmentor.com> wrote:
>
> >get_accountant("Bob");
> > or
> >find_by_name_and_department("Bob", "Accounting");
>
> >I'm sure you can think of some others that would read nicer than the SQL.
>
> Now throw another column into the mix. How many methods are you
> going to end up with? What will you have gained?
Nice point.
Now let's consider what all the combinations are. If we have
a single table with ten columns, then we have 1024 possible
column lists, so if we want a class for each such we need
You won't want all of those. Just a smallish subset. But every time you want a new one, you need a new class if the column set is different, and at least one new method.
What if we want to actually JOIN? If we limit ourselves to just two tables, we have to consider, again, all the possible column sets, (now 2^20, so a million possibilities instead of a thousand) and all the possible join conditions, in addition to all the possible WHERE conditions. Did I mention GROUP BY yet? And we haven't even really started to approach any *fancy* SQL.
Some problems are handled nicely by an API. Some aren't, and need an actual language. Things that need a language don't make good APIs. Consider something as comparatively low-power as regular expressions, and try to write an API for them. It's just a really bad idea. Now try to write an API that's as powerful as Java. It just doesn't make sense. Instead these problems are handled with a real *language*.
Marshall Received on Tue Mar 04 2008 - 21:01:56 CET