Foundations of ISA – Base paradigm – Scale ISA global
Iteration 2: Step into oo paradigm – state axiom – Part 3
class and Object
As exposed in the post Step into OO paradigm, Class and Object are distinct concepts.
The Classifiers define responsabilities to which must conform an Object of these categories.
On the other hand, an Object is specificaly caracterized by its identity and its current state.
The class belongs to M1 layer of the OMG's Four Modeling Layers (MOF) modeling classification. In a full Object Oriented world like ISA, Classes are also Objects. The class object is of course also a meta-object.
Together with the responsibility, the class meta-object defines the structure of the object conforming to the category it defines. More generally a class is the definition of the whole things that applies to an object category.
| A Class is an Object that defines a category of Object having the same characteristics (responsibility, structure, shared data and behaviors, etc.). |
Following this definition, a class is a replicable object over several systems, on one hand. On the other hand, it is a singleton. A singleton is the unique instance of an object in an execution environment.
The class object defines :
- A responsability (a semantic).
- The class structure : the fields, properties, attributes, operations.
- The life cycle major events : constructors and destructor.
- The object structure : the fields, properties, attributes, operations, listeners, is singleton, etc.
- The commun structure : name, namespace, inheritance relationships, class composition.
- The security features like access and rights.
- The transversal behaviors applying on the Class, the Object or the members (class invariant, pre-condition, post-treatment, etc.). They can also be added/removed at runtime.
In other words, having a rich Class object is the way to address some of the oo current limitations. Here the approach is to shift at the meta-model level.
Then, some of characteristics enumerated above directly to echo to paradigms like the Relational or the Aspect.
In ISA, the Classifiers and the other meta-objects are first class objects, without esoteric features like a static keyword, inner class, anonymous, etc.
Immutability
An immutable object is an object whose state cannot be modified after it is created. So it is warranted that any treatment even and in particular concurrent ones, cannot alter its state. Any “change”, results in the allocation of a new object. This is a way to avoid the common basic feature of oo that treatments may have side effects. This simplifies the concurrent programming by avoiding the need of lock on this kind of objects.
Well, that background established, it appears to me a pity to negate one of the basic feature of Object Orientation, the state axiom, by “just” freezing it!
So there are two kinds of objects, the real ones with a living state, and the amputated ones. In any case, immutability cannot be generalized to all objects.
This is the first reason why I don't like immutability. A conceptual motivation.
The second reason relates to bad performances of that approach. On one hand, immutability results in the allocation / deallocation of a large amount of objects. And on the other hand, many features can be far more efficient when implemented with algorithms running on mutable objects.
While immutability is mainly justified by its concurrent programming safety, a more Object Oriented feature should be provided. The lock mechanism is usually supported by programming languages. While very efficient, it is complex to use and it drives to bugs difficult to diagnose.
One can remark that an Object is a closed entity, so if command features of an object always runs in a same thread, its consistency is guaranteed.
| Remark : Even if queries are done in parallel by several use case objects, finally, the system state remain consistent. If queries may result in race conditions (gives unpredictable results), or if parallel commands may cross reference objects (giving deadlocks), this could be solved at the use case objects level simply by only allowing independent use cases parts to run together. |
So the proposed approach is just to allocate a thread per Object. This have many virtues:
- Remain purely in the scope of the oo paradigm.
- Completely transparent for developers.
- Address natively and transparently some categories of asynchronous features.
- Open a progress space for new hardware architectures by the multiplication of simple cores (impact on performance and scalability).
However, this path presents several challenges:
- Get it to work.
- Ensure consistency.
- Avoid the resources overconsumption.
- Run on several kind of hardware (some or many CPUs).
Try the approach of allocating one thread per Object.
| The immutability concept remains useful in operation contract. Here, it can be checked by the compiler following the “command / query” separation principle. |
Object versioning
This subject was evocated in the post axiom 4.Identity. This is because an object has a single identity, unique by definition in a committed state.
There are at least two situations where an object needs a versioning feature:
- If a version history is required for any reason.
- In asynchronous or concurent architectures (like ISA), where updates cannot be warrantied to be serialized.
In fact, only non-concurrent and non-historized local objects don't require a versioning mecanism.
To be sure that an object exist in a single state at a given point in time, together with the object identifier, a version identifier should be added. This is useful both to avoid updates on an outdated version of an object, and for object historization when this feature is required.
The versioning features are so common and so linked to object state and identity, that they must be incorporated to ISA.
Incorporate to ISA an Object versioning mechanism.