User Tools

Site Tools


Radical Object-Orientation (ROO)

Radical1) Object-Orientation is a view on object-orientation based on the original definition by Alan Kay who said:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning […])

Taken seriously Alan Kay envisions software to follow the same principles at play in organisms. A neuromuscular junction may serve as an example (image taken from Wikipedia article):

Nerve cell (A) and muscle cell (D) are biological cells and ACh (3, 4) is the message flowing between them.

ROO distills a couple of principles from this image/analogy:

  • The details of transforming input into output, i.e. a message arriving at a cell/object and a message leaving a cell/object, are hidden behind a facade, a membrane. Objects encapsulate their Logic. They are single operations in a network which creates software behaviour.
  • Objects do not know each other. A nerve cell has no idea of where its input messages are coming from or where its output is flowing to. Objects are oblivious of their surroundings. This is expressed in the Principle of Mutual Oblivion (PoMO).
  • Message flow is unidirectional. There is no request/response relationship between cells/objects; an object emitting a message does not wait for a return message to proceed with its task. There are no functional dependencies between objects.
  • The purpose of a cell/object is to transform input into output. It's not to keep close to other cells/objects or to build a chain or network of cells/objects. Rather it's a distinct responsibility to “wire-up” several objects to form a larger whole. This responsibility is called integration and is expressed in the Integration Operation Segregation Principle (IOSP).

The relationship between cells/objects can be abstracted like this:

As Alan Kay said:

The big idea is “messaging”

That is interpreted by ROO as meaning: software should be based not on control flow but on data flow.

This, of course, is not an end in itself. ROO's purpose is to create sustainable productivity.

Functions as objects

Usually classes are viewed as the basic building block of object-oriented code. They serve as templates for objects to be instantiated from.

ROO instead puts functions first. Functions are the containers of behaviour creating Logic. They are the processors of input messages and generators of output messages.

However, functions must conform to the IOSP and PoMO. They must be free of functional dependencies.

Classes are second. They serve functions by providing a means to share state if needed. Or they enable polymorphism by decoupling senders of messages from receivers. Classes are the lowest level in the ModuleHierarchy.

Hence to ROO functions are the true objects of Alan Kays vision. They are the primary concern in the AnalysisPhase and the DesignPhase.

ROO is called radical because it's going back to the roots of the term (lat. radix means root) and because from that follows a radically or at least quite different approach to organising code compared to mainstream object-orientation.
radicalobjectorientation.txt · Last modified: 2018/06/25 09:27 by fdadmin