Re: Mixing OO and DB

From: topmind <>
Date: Mon, 3 Mar 2008 10:13:08 -0800 (PST)
Message-ID: <>

David Cressey wrote:
> "Robert Martin" <> wrote in message
> news:2008030214431664440-unclebob_at_objectmentorcom...
> > On 2008-03-01 12:15:34 -0600, topmind <> said:
> >
> > >> Now you're just being a twit. It is very straightforward to
> > >> decouple application logic from the mechanism used to maintain the
> > >> persistent state of that system,
> > >
> > > Here you seem to be using the DB as *only* a dumb filing system.
> >
> > No. The DB is a powerful data management and query engine. The
> > application code takes the greatest advantage of that engine. But the
> > code that controls that engine on behalf of the application is isolated
> > into modules that are polymorphically decoupled from the main
> > application.
> >
> >
> It seems to me that this comment captures in a nutshell the basic disconnect
> between the DB crowd and the OO crowd. I'll confess that my perspective
> puts me firmly in the DB camp. But I'm trying to understand what the other
> camp is thinking (above the din).
> I think it's a matter of perspective: what you see depends on where you
> stand.
> Robert's comment is a succinct summary of what you might see if you stand
> inside an application, but outside all of the objects that are components of
> that application. In that case, isolating the SQL code into a single module
> achieves several goals.

I don't think that is what is being suggested, but merely that all SQL is wrapped behind methods. Where those methods are is a different matter.

> The first goal is that it localizes the maintenance
> requirement when the application must be ported to an environment that no
> longer supports SQL,

Which is what OO'ers want.

> or is modified in several other ways. The second goal
> is that it helps people who don't understand the data by isolating the code
> that they won't be able to read into a single module. There are other
> goals, but these two will do for now.
> Before I move on, I have to give an opinion based on my own data-centric
> world view. If you don't understand the data, then you don't know what
> you're talking about. In short, I completely fail to grasp how one can
> understand a system in terms of "behavior" without understanding the data
> that the behavior affects. This is something that it's going to take me
> years of lurking in comp.objects to grasp. And I suspect that, based on the
> experience of people like Marshall Spight, that I'm going to conclude, at
> the end of the day, that behavior is not the holy grail of computing.

What OO designs often do is *funnel* the view a given app developer has. (It can be done without OO also, but that's another topic.) They'll have an Employee object/class and the rules of encapsulation say: "These are the methods and the *only* methods you can use to access the Employee object. All Employee operations must go through them". Any new operations require going through the Interface Police (who go by various job titles, such as Chief Architect).

Its basically a bureaucracy to limit the damage of wayward and dumb employees or contractors. It may succeed at this goal, but at the expense of productivity and simplicity. Understanding is not the goal, but rather *control* is the goal. This is why your comments about "understanding the data" do not apply. The Martin-esque OOP style is to MAKE IGNORANCE TOLERABLE, not remove ignorance.

Paul Graham describes this nicely:


2. Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.

3. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list [data-oriented programming] becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.



> Now let met tell you my perspective: it's standing outside all the
> applications, and all the databases. Notice that I said databases, plural.
> There's no law that says that a system may not contain more than one
> database. However, there is a law that states, (I claim) that all the data
> in all the visible databases should conform to a single conceptual data
> model. Otherwise, the entire system is fragmented, from a conceptual data
> point of view, in ways that are practically impossible to manage. (I realize
> that a lot of real world situations are in exactly this situation, but my
> critcism stands.)
> From this point of view, an application is a "capsule", in the sense that
> the folks who use the term "encapsulation" mean it. I can't see what's
> going on inside the application. There could even be databases inside some
> of the applications, and the data in those databases need not conform to
> the unified conceptual data model I described above.
> From this point of view the comment Robert made, that provoked the
> response, is of no consequence. I don't care how the application is
> organized into modules until I "open the capsule" and start to peer into
> the internals of that application. At that point, I've shifted where I
> stand, and I've changed my perspective.
> In my original perspective, the single thing that ties together all the
> applications and all the databases that collaborate by sharing data is just
> one thing: data. If you understand the data, and you understand the
> (observable) behavior of each of the applications and each of the databases,
> you can understand the system. Otherwise, you can't understand the system.

-T- Received on Mon Mar 03 2008 - 19:13:08 CET

Original text of this message