Re: Object-relational impedence

From: David BL <davidbl_at_iinet.net.au>
Date: Sun, 16 Mar 2008 20:31:58 -0700 (PDT)
Message-ID: <91bde948-ba10-4b4f-924e-0eb9a6397dad_at_s19g2000prg.googlegroups.com>


On Mar 17, 4:53 am, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-03-14 03:46:58 -0500, David BL <davi..._at_iinet.net.au> said:
>
>
>
>
>
> > This has more to do with the
> > impedance mismatch than with some notion of "higher level". The RM is
> > suited (and only suited) to representing and querying information in
> > the form of large sets of propositions, whereas OO is suited (and only
> > suited) to building state machines within an abstract computational
> > machine. I would hardly call a set of propositions a state machine,
> > and I would hardly call a state machine a set of propositions.
> > Therefore there isn't really any overlap in the purpose of OO and RM.
> > Not surprisingly the best approach to build a system is often a hybrid
> > of the two. The idea to directly map a tuple (or "record") to an
> > object reveals confusion. A tuple is a non-scalar value representing
> > an immutable fact. An object is an identifiable state machine within
> > a larger abstract computational machine.
>
> > The RM has a sound mathematical basis, and it's clear that the RM will
> > stand the test of time. Any OO programmer who thinks it's reasonable
> > to wrap RM behind an ORM doesn't understand the RM, its fundamental
> > importance, the extent to which data can be decoupled from application
> > and the tremendous value in doing so.
>
> I was with you, and in violent agreement with you, until that last
> sentence. I think it *is* reasonable to use an ORM to adapt an RM to a
> specific application. This has nothing to do with which model is
> superior, or better, or more theoretical, or more valid, or etc. It's
> simply a matter of pragmatics.

Consider the following three groups of names

  1. int, double, point, circle, ellipse, square, string, set<int>, tuple, relation
  2. employee, company, invoice, manager, department
  3. mutex, textbutton, guiwindow, stack, queue, threadpool, printerproxy

Consider these as names for built-in types, structs or classes in a language like C++. I'm characterising the groups as follows

  1. These are value-types. A value is mathematically well defined, eternal and immutable. A value-type is a set of values plus operations on those values. Variables of a value-type can normally be assigned with any value of that type.
  2. These are conceptual things that aren't mathematically formalised and typically exist in time and space but are external to the abstract computational machine
  3. These designate types of objects where object means an identifiable abstract state machine embedded within an overall abstract computational machine. Objects do not generally represent values and do not in general support assignment. Objects always have identity, state and behaviour with respect to the abstract machine. Objects cannot be understood outside the computational machine in which they are defined.

For example a mutex may record the identity of the thread in the abstract machine that locked it so it can avoid self-deadlock from nested locks. A mutex will also ensure all other threads blocking on the mutex are queued in efficient wait states. Clearly a given mutex is meaningless outside the abstract machine in which it is defined.

As a definitional matter I characterise OO by its particular concern with class hierarchies from group C designed according to LSP and dynamic polymorphism on method invocation. LSP only concerns substitutability of one identifiable state machine for another according to contracted behaviours on method invocation. This LSP notion of substitutability is inapplicable to value types (ie group A). Indeed it is straightforward to show that subtyping of value types is impossible under LSP.

Both OO and RM need a rich set of value types from group A. I would expect an OOPL to be very good at defining types for groups A (as well as C, of course). This BTW is my biggest problem with Java which sucks at supporting user defined value types.

So what about the following?

struct Employee
{

    String name;
    String address;
    Date dateOfBirth;
};

This is a data struct using a name from group B. It is actually a tuple type and therefore more appropriately associated with a value type from group A! Nevertheless many OO programmers think of it in terms of group C.

I regard an Employee variable as merely a tuple variable that can be assigned with a tuple value. In a language like C++ I would treat this as a struct with public data members so I can get/set each of the fields. There is no need for encapsulation, having it take part in a class hierarchy, run time polymorphism and so on.

It doesn't make sense to define behaviours on a tuple variable that go beyond its ability to merely bind to a tuple value. For example, how could a tuple variable be expected to implement a method like FillOutTimeSheets()? Contrast this with state machines (ie objects) from group C like a mutex with methods like Acquire() and Release().

I would also suggest that it's adhoc to suppose that the identity of an Employee variable is associated with a particular human. Why can't there by any number of Employee variables that happen to store the same tuple value and therefore represent the same human? At issue is the meaning object identity. How do we perform identity testing? Do we compare the fields or just the addresses of the Employee variables? What does assignment mean? Do we allow a Clone() method? Does Clone() return the same employee or a different one?

The term ORM suggests there will be object classes (which I associate with group C) that have names associated with entity types from group B. I reject that idea. At most, a mapping layer should only support transparent access to logical views of the relational data using the full power of the RA and with the convenience of binding to tuple value types declared in the OOPL.

When I look at a book on OO I first look at their examples and ask whether the classes only come from group C. If not the book is discarded. As an example, the Design Patterns GoF book is reasonable because virtually every example (and there are dozens) use class names from group C.

An Employee class hierarchy is a remarkably silly candidate for teaching OO, and yet many OO authors use it. Received on Mon Mar 17 2008 - 04:31:58 CET

Original text of this message