Here's what I mean: There is a strange, yet unknown, unnamed "stuff" that actually creates behavior in software.

We'll get to what that is in the reality of programming in a later article. For now, just assume there exists this "magic dust" that can be used to create behavior or actual functionality.

All software can be programmed by simply arranging this "stuff" in the right way. It's like building a sand castle.

It consists solely of the "magic dust" brought into a useful shape.

But as you've probably experienced yourself: this is not built to last. It's fragile and even hard to erect in the first place.

That's why sand or clay is not used as is to build more durable structures; rather, it's formed into small units, into building blocks called bricks, from which buildings are then constructed.

Let's map that to the world of programming. What are the building blocks there? You might think it's objects. Wasn't that the whole point when Alan Kay coined the term? Maybe — but as it turned out, objects themselves don't do anything. It's actions that are the workhorses!

Actions are the bricks of software development! They compose the "magic dust" into units of certain functionality (operations), and they compose actions into even larger units of particular functionality at a higher level of abstraction (integrations). Like bricks get stacked to form walls.

To depict such hierarchies of actions composed into data flows at growing levels of abstraction more flexibly, the nesting can be replaced with a tree:

This is the first dimension of the software universe. Larger units of functional units — actions — are built from smaller ones through composition. And it all is made from... sand. No, sorry, "magic dust" aka "behavior-creating stuff".

It's actions all the way down — until you hit sand — to satisfy the user with beautiful behavior.

Now, on to objects.

Objects don't compose; they aggregate. They tie together multiple such hierarchies of data flows under one roof. And they add state if needed. State and non-root actions are hidden within the boundaries of an object. Only root actions are accessible; they get triggered by messages an object receives.

But objects also compose other objects into networks of collaborators. It's objects all the way down, too — until you hit just actions. This is where our journey into Alan Kay's vision started: objects needed to be connected. Who's responsible for that? Again, objects. At a higher level of abstraction.

Is this becoming a bit complicated? I hope not. Because I think it's a very straightforward, scalable meta-model of software. This model has two dimensions:

• Object dimension: Software is made up of a hierarchy of objects connected in uni-directional data flows. Messages are the data flowing between objects.

You can describe a software system by just looking at these object networks at different strata of abstraction.

However, since objects are (usually) described by nouns, this is only good for a pretty big picture. And it leaves in the dark how objects are actually creating behavior. The leaves in this object hierarchy can be quite big without giving a hint as to how they are processing messages.

That's why we have to look more closely — and what we find is that objects are made of actions. Actions are message processors, and they are very different from objects.

Hence the second dimension:

• Action dimension: Objects are made up of a hierarchy of actions connected in uni-directional data flows.

Objects aggregate actions and state. Objects compose other objects into data flows. This is best depicted by making the object hierarchy orthogonal to the action hierarchy:

Both dimensions are based on the "magic dust", the "stuff" that's actually creating behavior. Both are hierarchies of data flows. But the purpose of the dimensions is different:

• The action dimension is solely about behavior. Actions are denoted by verbs. Verbs are about activity. This is where more and more specific behavior gets abstracted from the generic "magic dust".

• The object dimension is about structure. Runtime structure. Here, actions and state get associated with each other. Objects are built on actions. "Bubbles" of closely related data flows are formed to isolate different parts of the totality of all data flows from each other at runtime. This is for runtime stability.

You can start out with "magic dust" alone plus state. But that does not scale. It becomes unwieldy very quickly. Think machine code or Assembler.

You can then wrap up "magic dust" into actions. That scales better if organized nicely into a hierarchy of data flows. But ultimately, this becomes brittle due to inconsistent state management. Think BASIC, Fortran, or C.

Enter objects! They wrap up actions plus state, forming black boxes hiding details to lower the risk of state inconsistencies.

Actions are concerned with ever more abstract behavior. Objects are concerned with ever more abstract structures aka aggregation of behavior.

No, this doesn't equate to a return to procedural programming. Procedural programming focuses on control flow rather than data flow.

Moreover, objects serve a crucial role as encapsulating entities. They act as "black boxes" that hide intricacies. In other words, they isolate action groups from one another and reduce the interdependence between different segments of behavior creation.

In Radical Object-Orientation, software behavior is shaped by actions housed within objects.

When it comes to software design, prioritizing behavior is key, with structure coming in second. This underscores the significance of the aforementioned data flow between actions. Structure, or how actions are organized into larger entities like objects, is of secondary importance. From a customer's perspective, the structural intricacies are often irrelevant; investments in structure don't directly enhance the user experience.

Objects are fundamentally about structure, but what do they collect into this structure?

Objects gather actions that share commonalities, such as related themes, identical internal states, or the utilization of the same API for external states.

In essence, objects are aggregators of actions and the shared states among them, as well as the data flows within these actions.

Consider this Storage object, for example:

This object combines a specific action with the state it manipulates. The state could be a list of names, with new entries being added. This list might be stored in memory or within a file. Assuming the latter, the file's structure would alter as new names are appended. It could look like this:

or like this:

The crucial question then becomes: What occurs within the append name action? Should this action remain opaque, or should it be dissected into smaller, more detailed sub-actions?

Radical Object-Orientation's elegance lies in its ability to refine actions in alignment with the principles derived for objects: the PoMO and the IOSP.

In this case that means, append name can be viewed as an integration. It’s an abstraction for a data flow between smaller, more focused actions:

• append one actually and only appends the incoming name to the list

• retrieve all actually and only loads the list of all names

This might seem trivial to you and it is in this example. But I am trying to explain a principle here which can be applied at any scale:

It’s data flows between actions all the way down inside of objects!

Actions can consist of a hierarchy of data flows between ever “smaller”, more fine grained, more general actions. Action are the true compositions inside of objects! Actions compose more specialized data flows from more general actions, i.e. they are integrations. Or they compose actual behavior from what later will be called logic. That’s what operations are doing in an action hierarchy.

In the above image append name is an integration and append one as well as retrieve all are operations composed into a data flow inside of append name.

This could go on indefinitely: any action can become an integration, if you like. But that’s a detail the environment in which objects are tied into networks of cooperation is not interested in. It’s hidden inside the object. It’s encapsulated like the state. That’s why objects are important even if actions do all the work. They draw opaque boundaries between different parts of behavior generation.

• Objects process messages by means of actions - but how exactly is hidden from the environment

• Objects are aggregations of actions sharing something: purpose and/or state (access)

• Objects hide the details of how state is structured and accessed

• Objects hide the details about how actions are structured

Data flows between actions are about behavior. Objects are about structuring all actions and state into manageable, useful groups.

Inside each object, specific actions are tasked with processing these messages, as shown here:

Alan Kay's original analogy didn't delve into these details, but it's quite clear that for the various messages an object handles, there should be dedicated components within the object to do the actual work. While an object might appear as a simple "black box" from the outside, it must have an organized internal structure.

Now, think about this: Consider the second figure again. What really drives the functionality, or the behavior, that users experience? Is it the network of interconnected objects, or is it the actions within them?

I firmly believe it's the actions. They narrate the process:

1. A name is first collected from the user.

2. This name is then added to an existing list of names.

3. The list is analyzed to generate a greeting message.

4. Finally, the greeting message is displayed to the user.

When we remove the objects and focus solely on these actions...

…the process becomes much simpler to understand and follow. This contrasts with the static nature of the first figure, which only shows objects without any indication of activity. Now, we see a story unfolding through actions.

It's quite intriguing that object-orientation, which originally focused on objects (nouns), has evolved to emphasize actions (verbs). This shift highlights that while objects provide a structural framework, actions bring the dynamic, behavior-driven aspect to the forefront, as shown here:

Therefore, I suggest that Radical Object-Orientation should prioritize actions, as they are the ones managing the messages. After all, the essence of Kay's vision was the concept of messaging.

Even when we momentarily set aside the objects, the impact of this approach is evident. It introduces a clear, unidirectional flow of data between actions, maintaining the Principle of Mutual Oblivion (PoMO). Moreover, the Integration Operation Segregation Principle (IOSP) remains applicable, marking a significant evolution from traditional coding practices to what was envisaged with Kay's revolutionary idea.

But what about their internal makeup? It's essential because an object needs a mechanism to ensure that an input message on a specific port results in an output message on a particular other. The ports for receiving and sending messages must be interconnected somehow, or else it's unclear whether an input will lead to the expected output. 🧐🤷

I suggest that the inner structure consists of various activities. While an object is generally seen as a "thing" represented by a noun, its components are actions, represented by verbs. All actions are of course transformations of some kind.

By labeling input ports with the actions they're linked to, it becomes simpler for integrations to direct messages appropriately.

And what about the output ports? Given that actions are expected to produce results (output messages), naming the output ports after the connected actions or the results they emit makes sense. This is straightforward when there's just one action involved, but multiple actions may require names based on the type of messages or results they release.

When an object performs an activity, it triggers a sequence of events internally. The output ports communicate these events to the outside world, indicating the completion of an activity or the production of a specific message.

Despite objects being autonomous according to the Principle of Mutual Oblivion (PoMO), their messages and ports evolve or are designed in tandem. Objects aim to be collaborative, not self-centered, and thus their interface is also shaped by the collective needs of other objects around them. Finding a balance between meeting others' needs and maintaining one's "authenticity" is key.

Objects form the building blocks of software in both mainstream and Radical Object-Orientation. However, Radical Object-Orientation further posits that these object compositions are essentially data flows at varying levels of abstraction.

And now Radical Object-Orientation introduces the idea that:

Objects are constituted by actions that connect input and output ports, potentially sharing state.

Unlike integrations, this structural approach to objects isn't about composition! The actions within an object don't combine to form larger actions; they're merely grouped together based on similarity. While composition integrates dissimilar elements into a cohesive whole by focusing on the connections, aggregation groups similar elements by simply collecting them.

The actions under an object's umbrella share commonalities, such as purpose or resource use, making it logical to aggregate them. In contrast, the objects within an integration share less, highlighting their value for cooperation in data flow processes (division of labor).

This leads us to a pivotal question: Radical Object-Orientation began with a focus on "things," denoted by nouns, and has evolved to emphasize actions, denoted by verbs, where the real behavior of code is created. So, why the initial focus on objects? Perhaps Radical Object-Orientation might be more aptly termed action-orientation? 😳😵

This might seem trivial to you because, after all, what else could objects be if not "things," and what else could we use but nouns to describe the entities that produce and consume messages? Wasn't this the core idea behind Alan Kay's vision: to make code and the process of thinking about code more tangible by establishing a correlation with the real world?

However, you will soon see that there is an alternative to this perspective. But first, let's fully grasp what it means for "things" to be represented by nouns, particularly in the context of traditional object-orientation.

Consider the following simple data flow between objects, which you should find relatable. The objects are identified by nouns, as is customary in mainstream object-orientation.

Imagine how messages might flow between these objects:

1. The UI object sends a message to the Storage object requesting data retrieval.

2. The Storage object then forwards the data to the Calculator object.

3. The Calculator object processes the data and sends its results to the Transformer object.

4. The Transformer object completes its task and sends the processed data back to the Storage object for storage.

The process initiated by the user through the UI object is successfully completed. Achievement unlocked!🥳

This scenario seems to align with what Alan Kay envisioned, with nouns actively passing messages among themselves. It resembles how biological cells communicate with each other using neurotransmitters.

Yet, I respectfully disagree with this interpretation.

First, the aforementioned description violates the Principle of Mutual Oblivion (PoMO) in Radical Object-Orientation:

• "The UI object sends a message to the Storage object"? This cannot be the case because no object should know any other. It's the role of the integration to connect them into a cohesive message flow. Only the integration knows that the UI and Storage objects should work together.

• "The Transformer object […] passes its result on to the Storage object"? This reflects the same misunderstanding. The Transformer object does not know about the Storage object. Their connection is facilitated by the integration.

This also raises questions about the nature of the messages. We've comfortably glossed over them so far, simply stating that "messages are flowing between objects." But what do these messages contain? Are they merely binary signals, akin to pressing a button, where the only variation is the presence or absence of a message? This is how neurotransmitters function, with variations only in quantity and frequency.

Or do messages convey specific data, such as a value for processing, as implied in the communication from the Storage to the Calculator object?

Perhaps messages also include a request, such as "Average this data" or "Remove duplicates from this data"?

Since objects are "things," as illustrated, it's reasonable to assume that Kay imagined them capable of processing various messages. For instance, the Storage object could load and store data, while the Calculator object could perform operations like averaging and summing data.

However, this would necessitate messages that carry not just data but also a discriminator to clarify the intended operation. For example, what action should the Calculator object take with the data "(1,2,3)"? Should it calculate the average or the sum?

Incorporating a discriminator within the message, such as "Average(1,2,3)" versus "Sum(1,2,3)," would clearly indicate to the recipient object the desired processing of the message's data.

This adjustment appears to be an improvement. It would also accommodate what is known in conventional object-orientation as polymorphism, where objects of different types can process the same message, making them functionally interchangeable. The object emitting a message need not worry about the specific nature of the recipient, as long as the latter understands the message.

In Radical Object-Orientation terminology, this shifts the responsibility to the integration: It must ensure that objects are connected in such a way that each one receives only the messages it is equipped to handle.

Now, a UI object no longer needs to be familiar with Calculator or Storage objects. The integration simply routes a "Sum(...)" or "Load()" message from the sender to the appropriate receiver.

Upon closer inspection, however, this approach does not resolve the PoMO violation. Why should the UI object have any knowledge about summing data, or why should the Storage object know about averaging data? Both are generating messages with specific requests, suggesting a predetermined sequence of actions, thereby linking the sender to certain types of receivers. This is not reflective of natural processes, where, for example, the neurotransmitter Acetylcholine can be received by either nerve cells or muscle cells, with the emitting nerve cell remaining oblivious to the type of receiving cell.

Radical Object-Orientation suggests that message-producing objects should not be "contaminated" with knowledge about their environment. They only know how to handle specific messages and the state they are responsible for. What happens upstream or downstream from them is of no concern. This approach significantly enhances the potential for reusing objects.

While message data can be tagged, they should not include a request. Then, how can we trigger a specific behavior in an object? It's a noun, a "thing" capable of many actions. How can a Calculator object know whether it's supposed to average the data rather than sum it?

One possibility is to have different connection points for different types of messages. Just as biological cells have various receptors for different neurotransmitter molecules, objects could have message receptors too.

As we can see, a discriminator is no longer necessary. The integration ensures that data-only messages are routed to the correct receptor of the receiving object. The producing object is thus decoupled from any specific receivers.

Unfortunately, this does not solve all issues related to message flow. Secondly, an "object network" based on "things" quickly leads to ambiguity.

To which receiver should a Calculator object's result be sent? Should it be transformed or stored directly? Should a sum be stored or transformed, should an average be stored or transformed?

Could tagging messages help? Perhaps. But why not employ the same approach as with receiving messages: add a "chimney" to a producing object. From there, messages produced are "excreted" into the environment. Integrations can then route them to a matching receptor on another object:

Problem solved! No more ambiguity! The message from one "chimney" is directed to the Transformer object, and the message from the other to the Storage object.

Or to be more precise: The problem is almost solved. The remaining question is: When does the producing object "send" a message through which "chimney"? But that's a discussion for another time.

Let me summarize our findings this way: Objects need specific "receptors" and "chimneys" to receive and release messages. Without these, it's challenging to connect them in a deterministic, unambiguous manner.

As a technical term, I propose "port" for both "receptors" and "chimneys":

• Input ports receive messages from other objects.

• Output ports release messages produced by an object into the environment.

Integration orchestrates message flows by connecting objects through their ports.

This outcome aligns neatly with Alan Kay's original vision, I believe. Objects are "things" denoted by nouns, offering much to their environment. To "trigger" a specific behavior, "the right button" must be pressed. That button is a port tuned to certain messages. And objects release different messages at different points, making it easy to integrate them into various downstream flows.

Does this sound reasonable?

Well, it introduces a level of differentiation that was absent from Alan Kay's biological analogy. However, it still might not be the best starting point for implementing Radical Object-Orientation.

We need to delve deeper...

However, it became clear that linking these objects could not be left to random processes, such as evolution, but required deliberate design. This responsibility is recognized as integration within Radical Object-Orientation.

Further exploration revealed that integrations themselves resemble objects: they, too, transform messages. This suggests that objects can be embedded within other objects, creating a nested structure. This notion is intriguing and practical, yet somewhat strange. Biological cells cannot be nested within each other, can they. Alan Kay’s idea has to be expanded.

Therefore, I propose the introduction of a new term: composition. While I have previously used this term, it was not in a systematic manner. Nevertheless, I believe it aptly describes the concept of integrations and operations within this context.

What is a composition?

A composition amalgamates complementary functional units to forge a new, higher-level functionality.

In Alan Kay's original vision, where objects were likened to biological cells, composition occurred in two forms:

1. Objects exist as distinct entities, such as a nerve cell or a muscle cell, each being a composition of unseen elements that together form a functional unit for message processing.

2. Objects are combined into a larger entity, for example a neuromuscular synapse consisting of a nerve cell and a muscle cell; the neuromuscular synapse is a more complex functional unit; it’s on a higher level of abstraction than its constituents.

Regrettably, the focus of Alan Kay was solely on individual objects, with the collective whole being overlooked and unnamed. This oversight was addressed by the IOSP, which recognized the assembly of objects into a data flow as an integration.

However, integrations can be deeply nested. At the foundational level, they incorporate objects, but at higher levels, they combine not just objects but other integrations. From an external viewpoint, these integrations are indistinguishable from the initial objects, leading to the suggestion of a unifying term: composition.

And this leads to the concept of "compositions all the way down," with compositions forming from other compositions. The terminal elements of this compositional hierarchy are termed operations, while the connecting nodes are integrations.

For integrations, it's clear they consist of other integrations and operations.

But what constitutes operations or the original objects?

They are composed of "stuff" responsible for state changes and transformations, possessing an atomic nature unlike the structured biological cells. This "stuff" lacks a relevant structure for our purposes. While we cannot alter this fundamental "stuff," we can design and construct objects aka operations from it.

The specifics of this "stuff" within a composition tree's operations will be discussed later. It's quite straightforward in programming terms.

For now, it suffices to say:

• Radical Object-Oriented programming forms a deep, compositional hierarchy.

• Intermediate nodes, termed integrations, assemble either other integrations or operations into a data flow.

• Terminal nodes, known as operations, combine "stuff" into a control flow.

To reiterate: The elements combined, whether into data or control flows, are complementary and distinct, like puzzle pieces. This is what elevates the whole above the sum of its parts, creating something novel not inherent in the individual components but emerging from creative problem-solving and design. You play the role of the intelligent designer.

But dependencies still exist; they're just not functional. It's not about one object's logic depending on another's.

Integrations depend on the functional units they combine, whether those are operations aka objects or other integrations. But integrations don't do anything on their own. Their job is simple: they just connect functional units into data flows.

Within such a data flow, a functional unit must be present and do its job. The entire data flow depends on it. But this isn't the same as a dependency between objects, which can have very complex tasks.

• Data flows are much easier to grasp. You don't need to dive deep into the hierarchy; you read them from left to right. They describe their function fully at a glance, on a single level of abstraction.

• Data flows hardly need testing. Well, almost. They're so straightforward. Integrating functional units is a breeze. Okay, that might be stretching it, but that's the gist. Data flows require far fewer tests because there are fewer paths within them. And if the integrated functional units are correct, then the integration will work too. You might want to verify this with so-called integration tests now and then; you'll want to feel how the integrated functional units work together. But that's nothing compared to the effort required to test operations.

So, the dependencies of integrations on integrated functional units are relatively harmless. No need to fear them. On the contrary: They are essential for abstractions. The abstract always builds on the detail; the whole always depends on its parts.

In Radical Object-Orientation, there's a rule:

Dependencies between functional units only run from higher to lower abstraction.

Dependencies point down the abstraction gradient. That’s what the Dependency Inversion Principle (DIP) was about all along. But why limit abstractions to interfaces as it’s mostly the case in DIP examples? Integrations are abstractions as well.

This gives you a great test: Whenever you see a dependency in your code, ask yourself whether the dependent is at a higher level of abstraction than the independent.

If yes, then the dependency is fine. If not, then your structure doesn't yet follow the IOSP of Radical Object-Orientation and does not implement a stratified design.

Take, for example, the dependencies in the "layered architecture" pattern. Here, the presentation layer depends on the business logic layer, which depends on the data access layer.

But is the presentation layer more abstract than the business logic layer, and the latter more abstract than the data access layer? No. They all operate at the same level of abstraction. They all do something completely different; their tasks are complementary.

When following the IOSP, essentially the same thing happens in every stratum, just at a different level of abstraction.

This means, in the layered model, the dependencies are functional. The layered model doesn't align with radical object orientation. That's why code in a layered software architecture is so hard to test. That's why there's so much talk about Inversion of Control (IoC), interfaces, and test surrogates.

The layered model doesn't handle dependencies well.

Dependencies aren't "evil"; you can't avoid them. They're like friction in mechanics: no machine works without friction. But you have to handle them carefully. For dependencies, this means: avoid functional dependencies, seek non-functional dependencies along the hierarchy of abstraction.

And now we're at a point where you should finally ask: What's actually being connected in these data flows and integrations? For Alan Kay, it's objects. But unfortunately, this concept doesn't scale very well.

Here, language doesn't strictly refer to different programming languages, but rather a set of primitives and rules for their combination, used to express and manipulate ideas at a certain level of abstraction. Each level uses the constructs of the level below it as its primitives, creating a layered architecture where higher levels abstract the complexity of the lower levels. For example, in electrical engineering, resistors and transistors (primitives at a lower level) are combined to create TTL circuits (a higher-level language), which are then used to build even higher structures like processors and memory systems. This approach allows for the modular construction of complex systems, where changes at one level can be made relatively independently of others.

Radical Object-Orientation aims to do the same for your software's code.

Alan Kay's objects are the primitives in the lowest stratum of a stratified design. They are the constructs of the most general language of an abstraction hierarchy. They're considered general because they can be reused in vastly different contexts, possibly even in other programs.

Objects as operations in a IOSP hierarchy are the ones that actually do something actively (similar to resistors and transistors). They generate behavior through the integration of logic. (More on this in a later post.)

In the context of IOSP, integrations no longer act on their own. They first integrate objects aka operations (similar to TTL circuits). Thus, they define constructs of a slightly more specialized, more abstract language above the primitives. In the next stratum above, integrations are composed of other integrations, but may also add more operations. And on the next level this repeats. They now form a much more specialized, more abstract language (similar to processors or memory).

This might sound familiar from software development: For example, when you code in C#, you're using a high-level language; it offers powerful abstractions, like foreach() or switch() with pattern matching. Beneath that is a less abstract language, the Intermediate Language (IL). Beneath that is an even less abstract language: Assembler. And at the bottom is the least abstract language, machine code.

I think you're glad you can express your solutions in C# or a similar high-level language rather than in machine code. By doing so, you stand at the top of a hierarchy of languages. That's why you're much more productive than developers from the 1960s.

Radical Object-Orientation seeks to achieve the same gains in productivity and comprehensibility for your code. That's the essence of IOSP. Eliminating functional dependencies makes it possible. However, this doesn't mean there are no dependencies left. But they are different and follow a clear rule.

P.S. Notice how Radical Object-Orientation isn't far from Functional Programming. Abelson and Sussman described stratified design with LISP; but it's equally possible with C#, Java, or Python. (Future articles will revolve around translating these concepts.)

For another view on stratified design check out this older article:

Ralf Westphals Newsletter

Stratified Design over Layered Design

Designing software with layers is common — and broken. It’s broken for two reasons: Layers suggest some form of abstraction; but layering very fundamentally is not about abstraction. Layering relies on functional dependencies which are hard to test and make software difficult to understand and evolve…

Read more

9 years ago · 1 like · Ralf Westphal

These are the core principles of Alan Kay's idea of object orientation for me, aka Radical Object-Orientation.

Objects communicate with unidirectional messages for a purpose that is larger, more comprehensive. They are parts of a whole. The whole is established and represented by integration.

But here's the kicker: From the outside, integration itself is indistinguishable from an object.

An object processes incoming messages into outgoing messages by leveraging its internal state.

Connected objects also process incoming messages into outgoing ones. They do this in a data flow, which you can think of as a production line. A message triggers a cascade of messages within the data flow at the first object, leading to messages at its end.

This means that the integration of objects behaves as a black box just like the individual objects it integrates. Integrations and their operations are in a whole-part relationship. Yet, it's evident that integrations are also parts of an even larger whole. Integrations can be integrated along with operations and other integrations. It’s a hierarchy of integrations with objects at the bottom.

The Integration Operation Segregation Principle (IOSP) allows for arbitrarily deep nesting downwards or abstraction upwards.

With each integration, complementary functional units - integrations or operations - are connected into a new whole within a data flow. The higher you go in such a hierarchy, the easier it becomes to initiate behavior with a message. And the higher you go, the more specialized and specific the integrations become.

An integration hierarchy reflects what constitutes our prosperity: a hierarchy of technological abstractions. Today, you get into a car and simply press a button to start it. Compare this convenience to the effort required to start a motor-driven vehicle 120 years ago. Or take your smartphone and make a call. Compare that with the effort needed to make a call 100 years ago.

You are surrounded by hierarchies of integration. You live at the peak of a deep hierarchy of abstractions.

This idea is not new, however. It was already described as a hierarchy of languages in the 1980s.

It also suggests the necessity for an explicit "intelligent design" to even connect cells for message communication.

How do biological cells with their neurotransmitters enact change? When a nerve cell produces Acetylcholine, it's oblivious to muscle cells that might respond.

A reaction to released neurotransmitters is only feasible if receptive cells are nearby. The spatial arrangement of cells is crucial for effectiveness. And how does this arrangement come about? Evolution led to "blueprints," along which development under environmental influence occurs. The result is a viable whole, an organism with its countless, neatly "packed" cells.

Evolution has thus led to the development of different cell types, neurotransmitters, and arrangements.

In software development, such evolution is unfortunately only possible in very limited domains and is called genetic programming. For the requirements your business world software needs to meet, you can't just call upon evolution. You're left with intelligent design, essentially playing God.

For your object orientation, this means making deliberate choices:

You must decide which objects should exist.

You must decide which messages should exist.

You must decide how objects should be connected to allow certain messages to flow.

The result is an integration: It's a new whole where individual objects are purposefully interconnected. From the various functionalities of the constituting objects, a comprehensive functionality at a higher level emerges.

An integration combines complementary functionalities into something new.

In Alan Kay's biological analogy, cells are highlighted as the main actors. But ultimately, it's about something larger, achieved only through the cooperation of all cells.

Unfortunately, Alan Kay forgot to mention the tissue, that organism form from cells, missing out on the necessity of integration.

Objects operate on messages. Hence, I call them operations.

Objects are combined into a new whole. This I call integration.

Integration is a distinct achievement. It's categorically different from operation. Therefore, for Radical Object-Orientation, I propose a second principle:

Integration Operation Segregation Principle (IOSP)

If you want to write radically object-oriented code, then operation and integration must be strictly separated. If you're a fan of the SOLID principles, you'll recognize this as a consistent application of the Single Responsibility Principle (SRP).

Ralf Westphals Newsletter

The Single Responsibility Principle

There is no question about how highly the Single Responsibility Principle (SRP) is valued among clean code developers. It’s the first of the SOLID principles for a reason. However… I have yet to meet a developer who’s able to succinctly explain what the SRP actually means. Especially hard to define seems its core term…

Read more

3 years ago · 1 like · Ralf Westphal

Remember: Where there's data flow, there needs to be somebody „to dig the ditch for the data for flow in“. The processing steps in a data flow don't do this themselves.

But integration is essential not only for "piecing together" objects into data flows. It's also why Radical Object-Orientation scales. The fact that integration resembles a biological cell with organelles - the objects it integrates - is no coincidence.

To get a different perspective on the IOSP you can read two earlier articles on it. They document how the principle underwent some change over time.

Ralf Westphals Newsletter

Integration Operation Segregation Principle (IOSP)

If there is one principle in clean code development that's my north star, then that's the Integration Operation Segregation Principle, the IOSP. It guides my code design, it guides my code refactoring, it guides my code reviews. It's very, very simple and clear. But it has a profound impact on a codebase. Sometimes it seems impossible to follow — but onc…

Read more

4 years ago · 5 likes · 3 comments · Ralf Westphal

Ralf Westphals Newsletter

IOSP 2.0

To me the Integration Operation Segregation Principle (IOSP) is maybe the most important principle of clean code development. The reason: It’s so simple to follow. Because you can recognize if it’s been applied by looking at the code alone. IOSP code has a certain form. A form that supports understandability and testability…

Read more

4 years ago · 1 like · 6 comments · Ralf Westphal

In mainstream object-orientation, one object commands another, waits for its execution report and the results. Then, it proceeds with its work until it issues commands to another object. In business, this is often called delegation: The manager delegates tasks to subordinates, controls their results, adds something, removes something, corrects, and then delegates again. Traditionally, companies are made up of a command-and-control hierarchy. So is your code.

Nature operates differently. No cell gives orders to another, controls their work, or even waits for them. Cells simply coexist side by side and „do their thing“ in response to what other cells around them are doing. Each is only responsible for perfectly performing its own function. There are no cells above or below them.

It's incredible that organisms from tardigrades to blue whales exist and live, which are much, much more complex than any software.

How is that possible? I think it's the paradigm. Command-and-control doesn't scale. Complexity cannot be managed with functional dependency.

The paradigm of nature is… flow. Not control flow, but data flow.

From my point of view, Alan Kay's core idea is therefore to build software from data flows.

The data flowing being messages.

For him, a data flow should consist of objects that each do their own thing independently and are connected in data flows. Some hold state, others do not.

Objects understand different input messages and produce different output messages. Data flow connections between them reflect this. In the image, an arrow only goes from one object to another if the messages produced are fundamentally acceptable to the receiving one.

Thus, several arrows can run to an object (e.g. C) because it can understand different messages. Or several arrows can run from an object because it can produce different messages (e.g. B).

Even though Alan Kay's idea has not become mainstream object-orientation and a data flow paradigm probably has not played a role for you so far, data flows are not unknown in software development.

Since Unix began its triumph in the early 1970s, there have been data flows on the command line, for example:

cat words.txt | sort | uniq > uniquewords.txt

The "object" cat lists the content of the file words.txt; the "object" sort sorts the content alphabetically; finally, the "object" uniq selects only the different words from it; in the end, the result flows into the file uniquewords.txt.

Unfortunately, this way of thinking has not extended into programming languages for applications. In C, in which Unix was programmed, there is no trace of it - and therefore later also not in C++, Java, C#.

You see, at the end of the 1960s and beginning of the 1970s, software development could have taken a different turn. Another paradigm - I even think: a better one - was in the air. But the opportunity was missed.

Maybe it was because people were afraid (or too tired) to deeply analyze Alan Kay's analogy. But therein lies a second important, relieving principle...

No part needs another part to function. What each part needs is appropriate input, that is, messages it understands, and a suitable environment. That's why a biological cell can survive outside the body in a Petri dish. Or why an engine can operate on a test stand without needing a chassis underneath or a body around it.

I call this functional independence.

Nature and even technology know no functional dependencies. All parts exist by themselves. They are ready to receive something that stimulates them to activity (aka their functionality). This includes producing something that can stimulate others to activity. Yet, no part is aware of who stimulates it or whom it stimulates.

The image highlights this difference from mainstream object orientation:

• Your mainstream objects know each other. They are made dependent on each other through request-response relationships. Object A needs Object B to do its job, for its own functionality; therefore, it sends a request to do something and waits for the result. Only then does it proceed with its own task. A's functionality depends on B's. That's why A and B are not connected by an arrow; instead, the dot at the end of the connecting line signifies that A is clinging to B.

• It's different with Radical Object Orientation as per Alan Kay. Here, Object S simply generates a message as part of its functionality, and that flows to Object T, which then does its job. S is not dependent on T, and T is not dependent on S.

Can you guess what this means for objects in your code? They can no longer refer to each other; there are no pointers between objects anymore. Object S has no reference to Object T. Objects in Radical Object-Orientation are fundamentally "wired" in a different manner.

Why is it good that objects are no longer functionally dependent on each other? They are easier to test. Because when you test an object, you don't have to worry about how the behavior of another object, from which the test subject requests a service, plays into the test. Such dependencies no longer exist. Each object works solely with the messages that flow into it and the state it holds.

Furthermore, you can understand such independent objects more easily. When you look at the code, you don't have to constantly wonder what's happening in objects to which a task is delegated. You don't have to constantly move up and down a hierarchy. Each object stands on its own. If you know the incoming message and its state, then by looking at just that one object, you can figure out what it does.

Sounds crazy, right? How can anything larger than a single object work at all then? Don't worry! You just have to be open to changing your way of thinking. The paradigm of Radical Object-Orientation is very different from that of structured programming or mainstream object-orientation. As I said, #radicaloo goes to the root.

For another take on functional independence this article:

Ralf Westphals Newsletter

Functional Dependencies

Functional dependencies are the bane of programming. They just cause problems: testability decreases, understandability decreases, function size increases the more functional dependencies proliferate. Hence in one word: Don’t! Don’t mess up your codebase with functional dependencies…

Read more

3 years ago · 2 likes · Ralf Westphal

This concept never really made it into mainstream programming by the end of the 1980s with C++ and subsequent languages.

But there's more to it!

Because the abstracted "circuit diagram" with objects suggests something that doesn't exist.

When you see two objects connected by an arrow, you probably instinctively think that it represents a request-response relationship between the objects and, therefore, the object from which the arrow originates knows the other object where the arrow ends. But that's not the case!

In nature, there are no request-response relationships. No cell (like a nerve cell) sends a message to another (like a muscle cell) and waits for a reply.

In fact, no cell "knows" another. In the neuromuscular junction, the nerve cell has no knowledge of a muscle cell and vice versa.

Both cells only recognize the messenger Acetylcholine: the nerve cell knows when and how to produce it and releases it; the muscle cell can detect it and responds accordingly.

Cells just live and weave alongside each other, oblivious to the others. They have no demands on each. Triggered by a message, they simply do what's in their nature: they change their state and possibly produce messages to „push out“.

I consider this a truly important feature in Alan Kay's analogy. It's definitely to be adopted in object-oriented programming to do justice to his idea. I find it so crucial that I want to distill it into a principle:

Principle of Mutual Oblivion (PoMO)

PoMO states: "Thou shalt not let thy objects know each other.“ They ignore one another and only share messages. There is a "message contract", but no cooperation or even subordination contract.

In the illustration, this is expressed by the flow of Acetylcholine coming out of the nerve cell, but not going directly to the muscle cell. And Acetylcholine flows towards the muscle cell, but it doesn't come directly from the nerve cell. Both flows are initially independent of each other. Only an explicit coupling allows messages to flow from one cell to the other.

The continuous arrow in the first abstraction of the biological analogy was a simplification. To deeply understand Alan Kay's idea, you need to look closer. The fundamental independence of objects is key!

Isn't that radically different from mainstream object-orientation? It leads to an entirely different paradigm of "wiring" objects.

For a different take on the PoMo see this article:

Ralf Westphals Newsletter

Principle of Mutual Oblivion (PoMO)

Do you know what object-orientation (OO) is? Really? Do you know, who invented the term? Do you know what he meant by it? Probably not, because… well, it’s usually not taught when you learn about OO programming with your favourite programming language…

Read more

3 years ago · 6 likes · 2 comments · Ralf Westphal

• Objects turn into simple geometric shapes, like an ellipse or a box, labeled with an object identifier.

• Messages transform into labeled arrows indicating what is exchanged.

Do you find this visual translation and simplification helpful? Does it make sense to you?

Great, because now we need to dive into a few specifics. Two of these were always mentioned by Alan Kay, and one was not.

1. Objects can have an internal state. They can store data across the processing of messages. Alan Kay referred to this as "local retention and protection and hiding of state-process". This is similar to biological cells, which have a state, like a certain contraction in muscle cells.

2. Messages flow strictly in one direction. For example, in the neuromuscular synapse, Acetylcholine flows only from the nerve cell to the muscle cell. The nerve cell is the producer of the neurotransmitter, and the muscle cell is the consumer. Given Alan Kay's careful choice of analogy, he must have intended the same unidirectional flow of messages for object orientation. However, as far as I know, Alan Kay never emphasized this.

3. Biological cells are living entities. Thus, they are autonomous. They are constantly active, not waiting for anything in particular. A muscle cell doesn't specifically wait for Acetylcholine from a nerve cell; it "does its thing" and changes its activity in response to Acetylcholine when received. Similarly, a nerve cell doesn't wait for its Acetylcholine to be received and processed by a muscle cell; it releases it and continues "with other things".

In summary:

Objects are autonomous functional units with an internal, hidden state, communicating only asynchronously and unidirectionally through messages.

This is what Alan Kay meant with his biological analogy. „The big idea is ‚messaging‘“ and from that follows communication between objects always is only one-way.

That's our first important insight gained from taking Alan Kay seriously and looking closer.

Is this reflected in your object-oriented code? I believe, not. Or if so, then because you’re using an Actor framework or deploying services.

But is that really necessary? Does object orientation truly require distribution across various threads or even processes with all its complexity? I don’t think so.

However, we need to look more closely and ultimately consider how a translation to the synchronous features of your programming language might be possible. 

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages" [1]

I believe it's worthwhile to take a closer look at his analogy - and then derive how radically object-oriented code could look.

I'll start with the obvious components of the analogy:

- Biological cells

- Messages (aka neurotransmitters)

Both components can be found, for instance, at the so-called neuromuscular junctions in your body.

There, nerve cells and muscle cells come together. They communicate, among other things, through the neurotransmitter molecule Acetylcholine (ACh). Let's break it down in simple terms, as ChatGPT would explain it:

The neuromuscular synapse is where a nerve cell (neuron) and a muscle cell (muscle fiber) work together:

1. The nerve cell sends electrical signals, called action potentials, down its long, thin extension called an axon.

2. At the end of the axon, there are small structures called synaptic terminals. These terminals release chemicals called neurotransmitters (Acetylcholine) into the space between the nerve cell and the muscle cell.

3. The neurotransmitters travel across this gap and bind to receptors on the surface of the muscle cell.

4. When the neurotransmitters bind to the receptors, they cause changes in the muscle cell that lead to the generation of an action potential in the muscle cell.

5. The action potential then travels along the muscle cell, causing it to contract and produce movement.

So, in summary, the nerve cell sends signals to the muscle cell using neurotransmitters, which then triggers the muscle cell to contract and create movement.

Alright? And that's exactly how your code should be structured and function. That was Alan Kay's idea.

Do you see how the two (types of) cells communicate using messages? That’s very important because, as you hopefully remember, „the big idea is ‚messaging‘“, as Alan Kay said.

But if you're not immediately sure how to implement this in C# or Java or TypeScript, I totally understand. I also had to ponder to recognize the principles embedded in this. It's helpful to simplify and formalize the complex biological reality. For that stay tuned for the next post.

[1] https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

If these statements resonate with you, perhaps you're interested in embarking on a little journey with me. In small steps, I'd like to introduce you to a different approach to object-orientation that can help you overcome uncertainties and arrive at cleaner solutions more easily. Personally, this alternative approach has greatly facilitated my software development efforts over the years. It's part of what I call "Programming with Ease."

From my perspective, this alternative approach represents a radical form of object-orientation. Radical, because it goes to the root of the concept (Latin: radix = root); radical, because it looks quite different from what you've likely heard about object-orientation thus far.

Are you ready for the red pill? Do you want to see how deep the rabbit hole goes?

Then buckle up…

Here's the original "definition" of the term "object":

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages" [1]

Coined in the late 1960s by the visionary behind many developments in software development: Alan Kay [2]

Did you know that object-orientation has its roots in biology?

And Alan Kay also stated what he considers the most important aspect of object-orientation:

"The big idea is 'messaging'" [3]

and

"messaging came at the very beginning" [1]

Did you know that messages are at the core of object-orientation and not, for example, classes or inheritance?

"[Object-orientation] is not even about classes. I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea." [3]

Therefore, it's no wonder to me that attempts to program cleanly with object-orientation since the late 1980s, with languages like C++ and its more or less closely related successors (e.g., Delphi, Java, C#, Ruby, Python), haven't been as successful as hoped. Yes, things have changed since C and Pascal or Fortran, but the potential inherent in Alan Kay's idea hasn't been fully realized.

For Alan Kay, object-orientation is quite simple:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." [1]

Messages are the brackets ("only messaging," "late-binding") around encapsulated state ("hiding of state-process").

Does your approach to object-orientation align with this conception? Most likely not. I believe that's because Alan Kay himself didn't explain enough about what he meant with his original idea. Even the language he co-developed, Smalltalk, didn't fully address this.

Yet, there's a lot to unpack in his analogy with biological cells. We just need to take a closer look. That's what I aim to do with further postings. Stay tuned if you're interested…

[1]  https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

[2] https://en.wikipedia.org/wiki/Alan_Kay

[3] https://wiki.c2.com/?AlanKayOnMessaging