User Tools

Site Tools


Principle of Mutual Oblivion (PoMO)

Alan Kay envisioned object-orientation to mimic nature: object should be like biological cells communicating with data messages instead of chemical compounds. See radical object-orientation for details.

Unfortunately Alan Kay did not produce any specific definition of what that means. An abstraction is missing. That's what the PoMO tries to deliver.

The PoMO distills from Alan Kay's image that in object-oriented systems…

Collaborating objects do not know each other and are connected by unidirectional message flow.

Objects in that sense are the workhorses of any software. Each contributes some service to the whole. They contain logic to create partial behaviour upon reception of an input message by producing output messages. Objects are the basic transformational building blocks of software.


Each of these objects has a narrow specification, a focused responsibility. Each reacts on some kind of input and produces an output - like a nerve cell or muscle cell does.

And none of these objects needs to know about the other objects. That's a very important conclusion derived from Alan Kay's image for object-orientation. Objects are not functionally dependent on each other. Objects don't call each other “for help”! Like no cell “calls” another to accomplish some task. In organisms there is no command-and-control between their cells. (Which does not mean that there are no feedback loops.)

Structuring code according to the PoMO creates small, loosely coupled functions containing logic. They are easy to test due to their independence.

But of course this begs the question how all those objects or functions are wire-up to form the whole of a software. If they don't know each other how can they send messages to each other? The answer is provided by the Integration Operation Segregation Principle (IOSP). Composition of wholes from object parts is a responsibility of it's own and must not be mixed with providing services through logic.

Data Flows

As the picture above shows, collaborating objects can be depicted as data flows. In a data flow control is not confined to just one processing step. Rather many processing steps can be active at the same time and produce data.

This is a more general view of software than provided by control flow diagrams like flow charts or sequence diagrams.

Since processing data by stepwise transformation of user input into output delivered to the user is the purpose of software, it seems data flows as processes are a natural representation of software. Software first and foremost is about behaviour, and functionality. For more about this see the explanations about the design phase.

pomo.txt · Last modified: 2018/06/04 10:57 by fdadmin