The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

The Theory of OO

Howdy. I'm doing some personal research into the epic conflict between relational theory and the OO approach, sometimes given the innocent name "impedence mismatch". This has featured on JoS quite a lot in recent times but I've had my eye on this topic for a while.

At the moment, I'm not interested in the impedence mismatch itself. In my travels, I've come across some references that OO is not a consistent approach, i.e. it's not backed up by a solid mathematical foundation. Procedural programming, I understand has some a sound basis. Relational theory is the theory of relations, there's predicate logic in there. That brings me to OO.

I've not been successful in turning up anything which talks about the theory of OO. I've heard that OO does not have a solid foundation and that leads to some problems inherent in OO programming, but found nothing concrete so...

Does anyone have know of any references to a critique of the *foundations* of the OO approach? It doesn't have to be online, anything in papyrus format would be useful.

Joel Goodwin Send private email
Tuesday, January 25, 2005
I have no idea if this is what you're looking for, but it seems to be full of academic blather so it must be important:

"This paper addresses the issue of giving a formal semantics to an object-oriented programming and specification language. ...The semantics is given by a translation of the constructs into the type system Fsub, an extension of the simple typed lambda-calculus by subtyping and parametric polymorphism"
Anony Coward
Tuesday, January 25, 2005
A university professor of mine recommended to me "A Theory of Objects" by Arbadi and Cardelli, when I asked about a theoretical underpinning to OO methodology.

Link to the book on
Jared Sulem Send private email
Tuesday, January 25, 2005
>  it's not backed up by a solid mathematical foundation.

There are any number of papers providing a solid foundation for OO. But they are just papers. What you get are languanges with the warts of things that actually exist.
son of parnas
Tuesday, January 25, 2005
Actually OO can be consistent same way the relational model is.

In the relational world, starting from a list of first order logical predicates, one has to create a system of relations that render all predicates in the list true.

Same thing in OO - UML diagrams for example are an 101 mapping to first order logical predicates. The only difference is that OO combines data and behavior without making any clear sepparation between the 2. Basically, 00 is not explicitly stating the axioms: data <> behavior; class = data + behavior.

The relational model needs not to make this distinction since it is dealing with data only.

However, the same relational model can be applied to statements around behavior (without any data). The model can be normalized, same way we normalize data models.

In the end, one would have to combine the data and behavior by specifing how data and behavior map together.

Basicaly, the correct, complete OO design process would look at:
- data related model
- behavior related model
- data to behavior mapping

The overall result is a normalized OO model.This has been my approach to OO design in the past 6-7 years with very good results.

For an example of correctly applied OO check the G4 book on "Design Patterns". Although the G4 did not think about normal models of this or that, their patterns are examples of normalized OO models.
Tuesday, January 25, 2005
What's the mathematical model for procedural programming?

I know functional programming has lambda-calculus, but I've never heard of an equivalent model for procedural programming.  I guess you could use lambda-calculus as long as none of your functions have side-effects?

Tuesday, January 25, 2005
Thanks for your comments.

I believe the "mathematical underpinning" of procedural programming is related to the theory of algorithms and the large body of information behind that, although I don't have any references on hand.

The most useful starting points regarding foundations of OO are at, which have some links to follow:

Most discussions about OO seem to be usually about the relational world vs. the object world. I've seen hints that OO was mathematically-based in the beginning but that formalistic approach has petered out in recent years.
Joel Goodwin Send private email
Wednesday, January 26, 2005
The relevant arguments are in "Object Oriented Software Construction, 2nd Edition" by Bertrand Meyer. Read it cover to cover, then continue with your research.
Daniel Daranas
Wednesday, January 26, 2005
OO is not a single model it is, perhaps, an approach.

There are messaging OO constructs where an object sends a message to itself and the message itself determines the action.  And then there is the encapsulated OO model where an object is perceived externally as a set of interfaces and internally as a set of properties, methods and events.

There are hybrid variations as well.
Simon Lucy Send private email
Wednesday, January 26, 2005
Dr. Mario Send private email
Wednesday, January 26, 2005
IMHO, OO programming has obvious philosophical foundations: Smalltalk and other genuine OO languages try to reproduce the way humans interact with their environment. They are metaphors of our world. is highly recommended if you find the topic interesting or if you're involved in language design. It shows that Smalltalk designers have spent their time doing philosophy instead of trying to prove obscure mathematical concepts.
Developer next door
Wednesday, January 26, 2005
Excellent and informative post by Dino.  I've never quite thought of it that way, but it makes perfect sense.
Wednesday, January 26, 2005
One of the most important developments regarding Objects and Relations is 'The Third Manifesto.'  Your research will be incomplete without studying this.

The main book is

The home page is

A good summary can be found in Date's 'Introduction to Database Systems.'

Central to the Third Manifesto are the two great blunders:

The first great blunder is that the object's class is equivalent to the table's header, and that the objects instances are equivalent to the tables row.

Instead they argue that the object's class is the object's type, domain of all values described within the relation.  Object instances are the equivalent to variables that identify values within that domain.

The second great blunder is the seperation of identity from value.  Two objects may have the same value, but have seperate identities.

There is interesting discussion on C2:
Ged Byrne Send private email
Friday, January 28, 2005
Thanks Ged. I've got Date's Introduction book, something I'm planning on breaking into soon, but haven't gone near the Third Manifesto yet.

(I've also been trying to find any links which don't involve the guys at DBDebunk as the site has an extreme focus - there, I didn't have to say anything sounding negative - on relational theory. Not many alternatives avaiable, it seems.)
Joel Goodwin Send private email
Friday, January 28, 2005
Ummm, without wanting to sound like an uneducated git, wouldn't it be useful to first ask the question why there needs to be a mathematical underpinning for O0 design?

I mean, if there isn't, all that you've proved is that mathematical theories aren't 100% appropriate for analysing software languages, because it is a quantifiable fact that object-oriented design works at least as well as any other programming paradigm yet found that DOES have a mathematical underpinning...

Just a thought.
Allison Newman Send private email
Monday, January 31, 2005
I started reading up on RDBMS theory, because the guys over a DBDebunk said that the modern concept of an RDBMS was, pretty much, a lie. I wanted to know what they really meant. Having worked with SQL for many years, I have found it ugly and uncooperative, I have felt that it encourages bad code. Then I discover the DBDebunk guys are dissing objects too.

Perhaps there's something in this, I thought. If there is something flawed with the foundations, you're building on shaky ground. There are a lot of people that get OO wrong and, what's more, it's easy to misinterpret the message of OO. Some projects screw up just because the class model was overabstracted or the wrong verbs/nouns/actors/behaviours/design patterns etc. had been chosen. OO often comes across as something vague and amorphous.

I wanted to know whether there was something to all of that. I have a feeling I won't find an answer; at the end of the day, it looks like it's down to personal opinion or theological belief system. So you are right, I should ask the question whether there needs to be a mathematical underpinning for OO design, and that *is* the question I am looking at.
Joel Goodwin Send private email
Monday, January 31, 2005
"I should ask the question whether there needs to be a mathematical underpinning for OO design, and that *is* the question I am looking at."

No there doesn't "need to be". The requirement for a software design technique is to help you produce good software - one that correctly solves a useful set of problems.
Daniel Daranas
Monday, January 31, 2005
This weekend we went out in the backcountry for skiing. At times we were in dense fog and we had to rely on our map & compass for navigation. It all went smooth and we reached or destination bulls-eye (and back :-) Compass navigation is not hard, IF you understand and know what you're doing.

Same principle applies to CS, OO models and RDBs: you need to understand and know what you're doing and then your development becomes smooth and effortless. Mathematics and formal methods will help you achieve the necessary understanding and objectiveness.

Read Richard Feynmann's books: "The Meaning of it All" or "Surely You're Joking, Mr. Feynman!". You may find some answers on why science needs mathematics and what's in a formula. It's all about reasoning correctly.
Monday, January 31, 2005
I agree with what you say, Daniel, but who decides what "correctly" is? I'm sure most of those daily WTF entries come from production systems which are considered an acceptable (correct?) solution for a useful problem. But often people can't even agree on whether a solution is a solution and that's the great dilemma that project managers often have to wrestle with.

I was asked: why waste your time with mathematics if it works?

Dino has provided one good answer to that question. I have another answer: I'm looking at the suggestion that *maybe* it doesn't work as well as Conventional Wisdom suggests. (It could also be a giant conspiracy, connected with the top secret Anomalous Materials lab at Black Mesa. That's not a theory I'm looking into at present.)

I think it's great that the world is just full of stuff that I don't know; my curiousity has been piqued and I want to learn some more.

Nonetheless, it's not going to stop me from implementing OO or RDBMS solutions over the coming years as I have for the last seven.
Joel Goodwin Send private email
Monday, January 31, 2005
Here is another reference I came across denouncing OO as outright evil and known to have suckled at Hell's fiery bosom:
Joel Goodwin Send private email
Monday, January 31, 2005
Daniel Daranas
Tuesday, February 01, 2005
I don't particularly like a lot of the material there, either (e.g. the straw man A + B argument for OOP bloat).
Joel Goodwin Send private email
Tuesday, February 01, 2005
I read parts of it some time ago and I didn't know whether some of its nonsense came from ignorance or malice. In his critique to OOSC2:

"Chapter 11
Design By Contract

Another title for this chapter could perhaps be "extreme validation". All the extra clauses and validation blocks are not without a price. For one, they provide more code to distract the eye and concentration, making it harder or longer to find the code that actually does something besides stand guard. Thus, there is the potential cost in time to find the code you are looking for, the potential errors introduced because the clutter confused one or interrupted one's thought, and possible errors introduced from changing a method's/routine's contents, but forgetting to change a validation condition to match. (A kind of mini Single Choice Principle violation.) Also see the comments about strong typing in chapter 2. There is something to be said about keeping intent and purpose of code lean and clean.

Also, a simple IF statement can be used in place of Require and Ensure. I am not sure special constructs are worth cluttering up a language with. They strike me as a little bit on the pedantic side. However, this is only a small gripe of mine."

Noone can write this and still pretend they've got a grasp about the subject.
Daniel Daranas
Tuesday, February 01, 2005
Yes, I actually like the idea of design by contract, despite only being available for Eiffel (correct me if I'm wrong).

I suppose the "bias" with the aforementioned site could be put down to the types of problems experienced. I've found interfaces to be exceptionally useful and more than just pushing switch statements around...
Joel Goodwin Send private email
Tuesday, February 01, 2005
"Yes, I actually like the idea of design by contract, despite only being available for Eiffel (correct me if I'm wrong)."

As for native support, I think you're right, but I've quite successfully used the techniques suggested to emulate it in other languages, eg by Miro Samek for C++:
Daniel Daranas
Tuesday, February 01, 2005
Interesting article. Takes me back to the mid 90s when I tried implementing OOP in 6502 assembly language with macros. (polymorphism was a bridge too far and ended up just being function pointers)
Joel Goodwin Send private email
Tuesday, February 01, 2005
"OOP" is just function pointers.  Enjoy.

Friday, February 04, 2005
As far as I know, it was a kind of evolution:

* information hiding
* abstract data types
* object orientation

So maybe I can deliver something concrete. I have been there at the conference:

Ole-Johan Dahl: The root of object-oriented programming: Simula 67.

The article is the "theory of OO".

best regards

Thorsten van Ellen
Thorsten van Ellen Send private email
Friday, February 18, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz