Re: The wisdom of the object mentors

From: Frans Bouma <>
Date: 27 Jun 2006 08:06:28 GMT
Message-Id: <>

Marshall wrote:

> Bart Wakker wrote:
> > writes:
> > >
> > > A algorithm could must obviously know about the data structure.
> >
> > Not at all! I'm currently writing many algorithms that get their
> > data passed in as java objects. The algorithm does not need to know
> > where the data came from and how it is stored in the database.
> "Where the data came from" is not the data structure.
> These methods you are writing, are they declared to receive
> arguments of type java.lang.Object? No? Then the objects
> support some interface, and that interface is the logical
> data structure.
> Yes? Then how do you get the data out of them? Reflection?
> Then you have some agreed-upon meta-protocol, whereby
> the logical data structure may be queried.
> An algorithm must obviously know about the data structure.

        Sure, but that's the datastructure of the application containing the algorithm, not the 'datastructure' the data resides in in the db. If I have 3 entities: Employee, Manager, Boardmember, and Manager is the subtype of Employee and Boardmember is the subtype of Manager and I define these entities as 3 tables, one for each entity, where each subtype has a PK which is also an FK to its supertype's PK, I then can work in my code with a Boardmember instance which contains the data which is stored in the employee and manager tables as well. It comes down to writing code which consumes entities on the level of how they exist in NIAM/ORM (Halpin/Nijssen, not on the level of an E/R model.

        The algorithm then works with a 'boardmember' while the data actually resides physically in 3 tables. So the algorithm doesn't know where the data is stored, it just works with boardmember objects.


Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
My .NET blog:
Microsoft MVP (C#) 
Received on Tue Jun 27 2006 - 10:06:28 CEST

Original text of this message