Re: Bussines objects

From: stork (tbandrow_at_mightyware.com)
Date: 02/27/05 

Date: 27 Feb 2005 10:49:20 -0800

TJB replied to:

> And they would be wrong. A Sales Order is a Composition that contains
1..n
> Order Lines; it also holds references to but does not aggregate a
Customer.
> The Order Lines each describe a quantity of a Product to be allocated
to the
> Order and hold a reference to that Product.

This is just shorthand for a relational representation. It's just
that, in C#, the address of the reference is its implicit foreign key.

>
> Your description looks more like an unnormalised Excel spread***
:-)

And Excel is more powerful than C# in some ways because it is a
declarative language whereas C# is merely imperative. If Excel were as
primitive as everyone says, we wouldn't have vast IT budgets trying to
replace just a few of the key spreadsheets.

> And they also would be wrong. Does the fact that a Sales Order is put
away
> in a drawer mean that its Lines become separate entities, except when
I want
> to look at the Order

Interestingly, this is exactly what C# and all OOP languages do.
There's no physical ordering of memory associated with an object. A
invoice and its components live scattered all across the heap and have
no spatial relationship whatsover.

The reality is that OOP systems are just short hand for a lightweight
relational system that uses memory addresses as primary keys. This is
easily observed by attempting to save an object to disk. All of a
sudden, those little references must be replaced by a more suitably
persistent identifier.

In a relational database, I can get all sorts of different views of the
data. I can get sales by item, sales by invoices, all from describing
the relationships of data once and only once. OOP is so infatuated
with hiding data that allowing one to produce new class types on the
fly (which SELECT does), would practically be heresy!

> As I have already said the benefit of OO design is the correct
allocation
> and encapsulation of behaviour relevant to the data it affects. I
suggest
> you look at the concept of Responsibility Driven Design; Timothy Budd
wrote

OOP design is shorthand for relational design and it is not nearly as
flexible and is already proven not as correct. OOP specifies
relationships between data by the use of a class hierarchy, and, in the
database world, this practiced stopped by the 1980s. Yes, you would,
in Pick on an RS/6000, maintain associations between items by either
containment (invoice line items in an invoice), or by physically
setting a pointer. The problem was that if you moved what was pointing
to, you had to move the pointer as well. So, we further in more purely
relational models abstract out the idea of what an instance of
something is by specifying its relationship through declarative foreign
keys.

There is enormous amount of evidence to suggest that object oriented
systems have to some degree not lived up to their promise, whereas data
driven approaches have always exceeded theirs. First off, they still
require relational databases to back them up. Secondly, they remain
extremely expensive to develop, even with tools as excellent as Visual
Studio.NET is today. And, finally, many of the things that are being
developed in object oriented systems are being replaced by declarative
systems. We used to do client server systems by hand, then, user
interface coding gave way to the declarative ease of use of HTML.
Even Windows Forms is being replaced by Avalon, which is ultimately a
declarative framework for everything known to mankind about user
interface design.

The reason for this is simple, stunningly simple. Object oriented
systems are imperative systems, and deal with things one at a time,
whereas, declarative systems deal with sets of things.

It remains a simple problem then to handle the transformation from the
schema of a user interface to a schema of a relational database, and
even things like XSLT prove that this is possible. .NET is in fact on
the verge of doing both and in doing so make itself obsolete. The user
interface designer of Visual Studio.NET is essentially a lightweight
database done through reflection. Most of the static forms cases are in
fact through property settings - clearly data only. SQL Server is
building powerful transformation features into it. Our future world
may well be a SQL Server that simply spits out user interfaces as just
another query.

OOP will go to the dustbin of history, and soon, because computers are
about data first and code second and OOP gets it backwards. In the
near future there will be tools that allow us to express declaratively
the relationships between items. In the near future, there will be no
code, only data.

Quantcast