Take the 2-minute tour ×

Alonzo Church's lambda calculus is the mathematical theory behind functional languages. Has object oriented programming some formal theory ?

share|improve this question
The simple answer is no, and that Object Oriented Programming has never had any formal mathematical theory driving its development. –  Justin L. Jun 24 '10 at 19:53
Hmm! perhaps that is why object orientedness is such a vaugue concept –  Tinku Jun 24 '10 at 19:59
It appeals to the programmer in this fashion: It makes thinking about the code easier. It "chunks" the necessary work into easy to work with abstractions. Take for instance, real life. I pick up my phone (an object) and dial a number (passing a request via a method). I don't need to know how it takes that number and connects me to the the other end..it just does. That simplicity is, i believe, what helped drive the thought pattern. GUI programming hammers this drive home..otherwise we'd be managing every tiny detail of the GUI (and go insane). Just my opinion. –  Caladain Jun 24 '10 at 20:38
But you are correct, there is no formal definition of OO. But it definitely exists, and is in heavy use :-) The wikipedia page lists a collection of "features" in a language that let it support OO. A good example of a language "growing" to enable OO where it didn't have it before would be the Ada83 to Ada95 jump. –  Caladain Jun 24 '10 at 20:40
not yet. I'm working on it. Check back in about 5 years ;-) –  Steven A. Lowe Jul 8 '10 at 17:32

7 Answers 7

Object Orientation comes from psychology not math.

If you think about it, it resemlbes more how humans work than how computers work. We think in objects that we class-ify. This table is a seating furniture.

Take Jean Piaget (1896-1980), who worked on a theory of children's cognitive development. Wikipedia says:


Some cognitive concepts he discovered:

Classification The ability to group objects together on the basis of common features. Class Inclusion The understanding, more advanced than simple classification, that some classes or sets of objects are also sub-sets of a larger class. (E.g. there is a class of objects called dogs. There is also a class called animals. But all dogs are also animals, so the class of animals includes that of dogs)

Read more: Piaget's developmental theory http://www.learningandteaching.info/learning/piaget.htm#ixzz1CipJeXyZ

share|improve this answer

OOP is a bit of a mixed bag of features that various languages implement in slightly different ways. There is no single formal definition of OOP but a number of people have tried to describe OOP based on the common features of languages that claim to be object oriented. From Wikipedia:

Benjamin Cuire Pierce and some other researchers view as futile any attempt to distill OOP to a minimal set of features. He nonetheless identifies fundamental features that support the OOP programming style in most object-oriented languages:

  • Subtype polymorphism
  • object inheritance (or delegation)
share|improve this answer
IMO we can not call these features formal theory –  Tinku Jun 24 '10 at 19:55

I'd check out wikipedia's page on OO http://en.wikipedia.org/wiki/Object-oriented_programming It's got the principles and fundamentals and history.

My understanding is that it was an evolutionary progression of features and ideas in a variety of languages that finally came together with the push in the 90's for GUI's going mainstream. But i could be horribly wrong :-D

Edit: What's even more interesting is that people still argue about "what makes an OO language OO"..i'm not sure the feature set is even generally agreed upon that defines an OO language.

share|improve this answer

One formal definition I've run into for strongly defining and constraining subtyping is the Liskov Substitution Principle. It is certainly not all of object-oriented programming, but yet it might serve as a link into the formal foundations in development.

share|improve this answer

Abadi and Cardelli have written A Theory Of Objects, you might want to look into that. Another exposition is given the venerable TAPL (IIRC, they approach objects as recursive records in a typed lambda calculus). I don't really know much about this stuff.

share|improve this answer

What about Petri nets? Object might be a place, a composition an arc, messages tokens. I have not though about it very thoroughly, so there might be some flaws I am not aware of, but you can investigate - there is a lot of theoretical works related to Petri nets.

I found this, for example:

share|improve this answer

The history (simplified) goes that way :

First came the spagetti code. Then came the procedural code (Like C and Pascal). Then came modular code (Like in modula). Then came the object oriented code (Like in smalltalk).

Whats the porpuse of object oriented programming ?

You can only understand if you recall history.

At first code was simply a sequence of instructions given to the computer (Literally in binary representation) Then came the macro assemblers. With mneomonics for instructions. Then people detected that sometimes you have code that is repeated around. So they created GOTO. But GOTO (Or branch or jump etc) cannot return back to where it was called, and cannot give direct return values, nor can accept formal parameters (You had to use global variables). Against the first problem, people created subroutines (GOSUB-like). Groups of instructions that could be called repeatedly and return to where it was called. Then people detected that routines would be more usefull if they had parameters and could return values. For this they created functions, procedures and calling conventions. Those abstractions where called on top of an abstraction called the stack. The stack allows formal parameters, return values and something called recursion (direct or indirect). With the stack and the ability for a function to be called arbitrarely (even indirectly), came the procedural programming, solving the GOTO problem. But then came the large projects, and the necessity to group procedures into logical entities (modules).

Thats where you will understand why object oriented programming evolved.

When you have a module, you have module local variables.

Think about this :

Module MyScreenModule;

Var X, Y : Integer;

Procedure SetX(value : Integer);
Procedure SetY(value : Integer);

End Module.

There are X and Y variables that are local to that module. In that example, X and Y holds the position of the cursor. But lets suppose your computer has more than one screen. So what can we do now ? X and Y alone arent able to hold the X and Y values of all screens you have. You need a way to INSTANTIATE that information. Thats where the jump from modular programming goes to object oriented programming.

In a non object oriented language you would usually do :

Var Screens :  Array of Record X, Y : Integer End;

And then pass a index value to each module call :

Procedure SetX(ScreenID : Integer; X : Integer);
Procedure SetY(ScreenID : Integer; Y : Integer);

Here screenid refers to wich of the multiple screens that you are talking about.

Object oriented inverts the relationship. Instead of a module with multiple data instances (Effectively what screenid does here), you make the data the first class citizen and attach code to it, like this :

Class MyScreenModule;

Field X, Y : Integer;

Procedure SetX(value : Integer);
Procedure SetY(value : Integer);

End Class.

Its almost same thing as a module ! Now you instantiate it by providing a implicit pointer to a instance, like :

ScreenNumber1 := New MyScreenModule;

And then proceed to use it :


You effectively turned your modular programming into a multi-instance programming where the variable holding the module pointer itself differentiates each instance. Gotcha ?

Its an evolution of the abstraction.

So now you have multiple-instances, whats the next level ?

Polymorphism. Etc. The rest is pretty standard object oriented lessons.

Whats the point ? The point is that object oriented (like procedures, like subroutines etc) did not evolve from a theoretical standpoint but from the praxys of many coders working around decades. Its a evolution of computer programming, a continual evolution.

share|improve this answer

Your Answer


