Foundations of ISA – Base paradigm – Scale ISA global

Iteration 2: Step into oo paradigm – state axiom – Part 2

Fields and Relationships

The object members values are its state. Most oo languages do not make distinction between the fields and the relationships. In both cases, they are direct reference to  other objects (except for primitive types). Most languages, but not all: UML makes the distinction. And that seems not to be a coincidence, since UML comes from the modeling world. It has been therefore widely influenced by the previous modeling paradigm: entity-relationship (Relational).

In fact, even UML doesn't make the distinction. This leads to some confusion and to practices diversity. A common usage is to reserve the fields to “datatype” like primitive types and enumerations, and to use the associations elsewhere (Cf. UML Best Practice: Attribute or Association).

Remember that one of the weaknesses of the object-Oriented paradigm is precisely its way to deal with sets. And in particular, with the sets of other entities with which an object is related (Cf. Available paradigms overview § OO cons). This is where the Relational paradigm, by definition, is very good. And where the unitary essence of the oo is a disadvantage.
So thanks to UML to have maintained that useful abstraction to designers, developers and for the efficiency. Introduce relationship as one kind of members could improve performance and scalability but also provides a base for constraints (multiplicity for instance). Instead of a simple direct pointer to objects, it is valuable to have a built-in artifact that introduces an indirection for associations. It could make the support of collections more easy and accurate.

Another possible distinction between a field and a relationship comes on how changes to the referenced object (string, integer or more structured object) affect the object state. For fields, any modification implies a state evolution. This is not always the case for objects referenced thru a relationship: If the relationship is a composition, it alter the state; if a change occurs on the set of related objects, the object state is also altered; but otherwise, when the change is just on the linked object by itself, the object state is not affected.

So, the difference to be made between field and relationship becomes clearer: If a simple direct static reference is sufficient to relate with an other object (like explicit multiplicity: 0..1, 2..4), then we must use a simple Field; but when the link requires more features, some dynamics in other words (constraint, scaling, lazy-loading, joined life cycles, association class, fine state change, bidirectional, etc.), we have to prefer a Relationship.

ISA must distinguish fields and relationships in order to compensate one oo limits on related sets.

Fields and Properties

There is another kind of state member that have to be considered : the concept of Property encountered natively in the dot NET world or thru beans in the Java one. OK. But verily, what is a property ?

Like for Relationships, the Property concept has also to be clarified.

Conclusion : There is no general agreement on what is a property.

So, I will try to give a definition of what is a property in the scope of ISA.

Examples: The color of a car, its power; the fusion point of iron.

A Property results of what is the object in its construction (constructor). To be changed, a property require an action to be done on the object (operation). A property is measurable, accessible; but more or less easily (public, component, protected).
Therefore, a property is read only.
A Property can be mapped to a Field, a Relationship or to a Method for computed fields (the age of a person for instance).

With this definition, an object can never be directly modified externally. This could widely limit the functionality on an Object (think to user interface objects for instance). So, at least for ease of use, the Attribute concept is also defined in the scope of ISA.

Examples: The registration number of a car; the color of a word in a word processor; add the “first aider” capability to an employee (add a class).

An Attribute of an object is the results of a solicitation by its environment (message). To be changed, an attribute has to be modified on itself. An attribute is readable and writable.
An attribute could be mapped to a Field, a Relationship or to class addition / removal.

To sum up, it appear that Property and Attribute are means to segregate access on members between read and read/write, between not altering the object state or changing it, between queries and commands. Sound familiar ? Finally these concepts are just usefull in the context of supporting the command and query separation principle of Eiffel.
It is also a means to support the uniform access principle, giving a similar access for object client regardless of how the data is implemented internally.

Consider to have Property and Attribute in order to expose visible data. This should be done in studying the interest for ISA to follow the command and query separation principle.