Foundations of ISA – Base – Scale ISA global

Iteration 2: Step into – State axiom – Part 1

...Previously on ISA blog...
 …Previously on ISA blog…

Axioms 4. and 5. State

The  is often not in the of designs. Design mostly operates with Classifiers. Therefore the  more closely related  axioms  are orphans: The N°4.  and the N° 5. State. Although the 2 contribute to the  ,  and  are not the same. In most languages, the  (the individual) is only represented by a memory address, a reference, a pointer, an handle and the like. At contrary, Dynamic languages address each individual in itself. If you can add or remove members to a given , it makes it much more flexible and easy to deal with over the time. The Object State is treated almost in three same way : just having an in memory representation (often even not specified). Ignoring the whole life cycle of an Object (creation, destruction, events, communication, persistency, erasing, …). 

What's a State ?

I will treat the State axiom in the same way I have did for the one: Thru major subjects that I can identify. Before doing that, I would recall what has been found in the  Identity axiom post about versioning and structural objects: The States of Objects and of meta-objects like are different. Moreover, this subject is wide and often not much studied elsewhere. Therefore this post is divided in several parts, in particular for each of the modeling level axis.

Before all, what is the definition of the Object State? There are varying definitions, but converging, like:

  1. The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties … (G. Booch, R. A. Maksimchuk)
  2. The state of an object is defined by the state of the instance variables of the object.
  3. What the objects have, Student have a first name, last name, age, etc 

In a previous post I have given the following one: “The values of the Object fields and relationships.” That's the most simple and accurate I can found. It relates to the data set of an Object and of  their values. Please, notice that I distinguish fields and relationships. I will discuss that below.

End of the story ?
Yes in almost all cases in the computer science literature.
I think this is widely insufficient because many points are not treated. Not convinced ? Ok but what do you do of :

  • The need of the State Design Pattern.
  • The need of the Observer Design Pattern.
  • Object life cycle, as defined in UML for .
  • Things like Microsoft.Web.Administration.ObjectState or javax.jdo.ObjectState
  • The distinction between a field and a relationship (and about agregation and composition).
  • The as pointed previously.
  • The distinction between Object and as also defined in the previous post.
  • Static fields. rigolade
  • The need of the Singleton Design Pattern.
  • Immutable object. rigolade

State of Objects

Here is a list of subjects I would like to have a look in the perpective of an incorporation in ISA  :

  • Life cycle
  • Basic features (Design Patterns)
  • Advanced features (invariant, pre and post condition, command and query separation).
  • Fields and Relationships
  • Fields and Properties
  • and Object
  • Immutability
  • Versioning

Life cycle and basic Design Patterns

All objects have a life cycle. The simplest one has only 3 states: Start, Initialized, End; and 2 transitions: Construct, Destroy. This is the sole life cycle that is supported by almost all systems and languages.

But there are many other possible life cycles of course. Some are related to runtime systems, like the above one, others are domain specific. In the later case, in wide organisations, they are usually expressed via UML state machine or BPMN diagrams. Anyway, they are so common, that they are the purpose of design patterns (State, Observer, Singleton, Memento).

There is no reason to leave the state management external to objects, because it is one of the base axiom of the . No reason to let separated and of varying implementations, those things that are well known by practitioners.
At contrary, the incorporation of these features thinly linked to is a way to address the unavoidable complexity of the world in a regular and common way.

ISA must natively support the Object state and life cycle features, for both axis : system and domain specific. 

Advanced features

Some platforms offers more advanced features around the management of object state. This is particularly the case of Eiffel.

Altering the object state is not an anodyne operation because of possible side effects (consistency, persistence, concurrency, notification, etc.). So, it appears valuable to have some advanced features to deal with updates. Therefore concepts like invariant, method pre and post conditions, command and query separation principle should be incorporated at least as optional properties of classes.

Consider incorporate state related advanced features provided by Eiffel.

 

Related posts:

  1. The State axiom – Part 3
  2. The Identity axiom
  3. The State axiom – Part 2
  4. The State axiom – Part 4
  5. Available paradigms overview
Tags: (04 01 - Base paradigm), Background, Foundations, Language, Paradigm, Requirement