OiRc-0002 What a lo-ong strange trip its been. (Apologies to the Grateful Dead.)

Sometimes I wonder how I got to where I am in my profession.

I'm a manager in IT (Information Technology), formerly known as DP (Data Processing,) though it was known for a while in Canada by the sexier moniker of Informatics.

I can't help but thank my high school arthitecture teacher, Stan Klasa, who prompty disabused me of a career in architecture in Montreal Quebec Canada. Its no way to make a living. You'll never get rich and the decisions are all made else where. He meant Toronto, Ontario, Canada but he might as well have said Mars.

I sort of dropped architecture as a profession/vocation, bounced around becoming what Grace Slick called a person our parents warned us about went to CEGEP (Wikipedia provides a definition: Collège d'enseignement général et professionnel translates to College of General and Vocational Education which sort of what junior college is in the 'States) and had a job selling screws (industrial fasteners.)

I bumped into a friend of mine, Andrew Morrow, who I'd met in the math lab at Dawson College, the aforementionned CEGEP, and he had a job going where he worked.

I just realized that this is a topic that I do not want to go into into too much detail because I realized that I refered to most of my collegues in less that glowing terms: Most programmers should be selling shoes.

Later, after years of handling other peoples orphan problems, those for which there was no easy solution, I came back to a simple problem: How do you model a wall?

Think about it... Its an everyday object, a wall. I've written about it on my wiki and one article says it best. (Unfortunately, I can't garantee that the page is always available so I'm sort of adapting it here. Quoting one's self is something that should be avoided but nobody's persuing the subject.)

The metaphorical wall

What is the difference between:

* a pile of bricks and a sack of mortar at Home Depot,
* a garden wall keeping the flower bed out of the lawn and
* the cuppola of the Piazza Duomo in Florence.

If you've only leaned about objects in computer science classes, you probably can't even comprehend the unstated question never mind its answer.

None of your schooling has prepared you to perceive the question and all your schooling has conspired against ''grocking'' the answer.

In object-oriented thinking there is no difference.

All three are composed of bricks and mortar. The first is raw material at the store. The next is a mundane partition. The last is a masterpiece of Italian Renaissance architecture.

This brings us to an observation:

In object-oriented thinking, contained objects never know about their containers unless provided an explicit reference.

This existential clap-trap is saying that a brick can't know its part of a wall until you alter the definition of a brick to include a pointer to the wall that its in.

As broken fingernails on the hands of masons, demolition workers and prisoners everywehere can attest, bricks that are in a wall definitely don't need to be explicitely told they're in a wall.

In object-oriented thinking, you can't have different types of walls (indeed, you can't even have one realistic wall.)

So what's missing?

Relationships

None of the implementations of object-oriented systems, languages, modeling techniques etcetera (and few of the researchers [[and even fewer of the people currently messing up in IT shops around the globe,]) have any mechanisms capable of representing or dealing with relationships.

As we have (should) have learned since the mid-nineteen-eighties with the introduction of DB2, relational databases and the attempts at creating a relational calculus, (before the profitability of database companies and other vendors put the kibosh on research and education,) relationships come in very, very few flavors:

• 1:1 - one to one
• 1:N - one to many
• N:1 - many to one
• N:M - many to many

That's it. There are no more possible cases.

There are modifiers of course:

{0}|1{_}|{N} <-> {M}|1{_}|{0}

Meaning:

• can you possibly have no partipants and
• is having only one participant existentially different from having none or many participants and
• can you possibly have many participants in one side or the other of the relationship?

The mechanisms and complications immediately obscure that while basic and fundamental, trying to understand object architecture without relationships is akin to trying to understand physics without forces.

As LeCorbusier said: ''Architecture is about space.''

That was an elliptical way of saying that the relationships, however banal, are more important than the material being related.

And indeed our word for wall and the concept it embodies doesn't care about the composition of the wall or its function. A wall is an arrangement of objects in such a way as to exhibit certain relationships beteen themselves. It is entirely self-referential and scaleless.

Think of relationships as static (cached) or dynamic (query result) embodiments of the raisons d'etre for the objects in the first place.

I don't want to belabor the point or stretch the analogy but the moment you start seeing the relationships you start seeing their pervasiveness.

We will return to this theme and how it influenced my view of objects, instances, relationships and connections in the later blog entries.