Radical Object-Orientation #0E: What Objects Encapsulate
Data flows between actions all the way down
You might be pondering: If the essence of Radical Object-Orientation leads us to a point where data moves between actions, what role do objects play initially? Doesn't this approach circle back to a form of procedural programming?
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.