Foundations of ISA – Base paradigm – Scale ISA global

Iteration 2: Step into OO paradigm

What is an object ?

First of all it is an entity that has a frontier between its inside and the outside environment. It encapsulates its body. Making this body inaccessible except thru an interface.
Encapsulation, border, is to me the most important concept defining what is fundamentally an object. All others characteristics stem from that fundamental axiom.

Axioms of OO:

1. Encapsulation: The Object body is separated from its environment by a frontier.
2. interface: The only way for the environment to communicate with the Object.
3. Behavior: The set of well defined behaviors the Object is expected to offer.
4. identity: It is the way for the environment to recognize unambiguously the Object.
5. State: The values of the Object fields and relationships.

object-axioms2

Additionally to these axioms, an object may also be connected to its environment thru dependencies. Since dependencies cannot be considered to be essential when defining the Object concept, it is in practice an important facet.

Behind the object

What is there behind the object concept? What's the Deus ex machina that's make this approach so efficient ?

The Software Architecture subject is mostly about Separation Of Concerns. There are many references on this principle and I invite the readers to have a look to each of these ones.

• DevIQ
• Wikipedia
• Effective Software Design
• Microsoft

And finally the most precious reference for our discussion was found at Object Mentor. It was written by Robert C. Martin  SRP: The Single Responsibility Principle. I reproduced this chapter in this blog.

1. The first thing that appears is that OO is a way to follow the Separation Of Concerns principle. That is the first key of this paradigm. This maps in particular to axioms 1.Encapsulation, 2.interface and 3.Behavior.
2. The second thing is that responsibility applies to class (more generally to classifier in the UML sense). In the Rectangle or Modem examples of SRP: The Single Responsibility Principle, The Classifiers  Geometric Rectangle or Connection are illustrations of that.
3. Consequently, and that's the third point, class and Object are distinct concepts. This can be seen as obvious, but please be careful with obvious things…
   While interface only specifies the responsibility of an Objects category; a class describes moreover the way (the structure) to realize it. The Classifiers define responsabilities to which must conforms an Object of these categories.
   On the other hand, an Object is specificaly caracterized by its identity and its current state.
   Therefore, this point relates in particular to axioms 2.interface, 3.Behavior and 4.Identity, 5. State.
4. Final fourth point, the Object is often not in the scope of designs. Design mostly operates with Classifiers (here in the all cited references, where the only subject is about Classifiers). Therefore the Object more closely related  axioms  are orphans: The N°4.Identity  and the N° 5. State.

No really, although the 2 contribute to the OO paradigm, Object and class are not the same.

First look at axioms 4.Identity and 5. State

In most languages, the Identity (the individual) is only represented by a memory address, a reference, a pointer, an handle and the like.
Look at the examples in SRP: The Single Responsibility Principle: to supports the real world objects Rectangle and Modem, one need to create numerous static structures as classes and interfaces, or even to apply some Design Patterns. But, as big as your talent can be to design software, you cannot imagine all possible situations and responsibilities. For instance, what is happening if you Rectangle shape Object is transformed to become a Circle!
That's where Dynamic languages can come into play. They address each individual object in itself. If you can add or remove members to a given Object, it makes it much more flexible and easy to deal with over the time.
That's really what we want, because finally Rectangles and Modems are definitely real world objects. And we make programs to manage them.

The Object State is treated almost in the 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, …).

Next step

This fourth point (IV) does not exhaust the subject of the consequences of the 4.Identity and  5. State axioms, but that's enough for this post. This point, like static versus dynamic language, will be more deeply discused in the future.

To sum up :

• It is essential to separate responsibilities. The static structures like Class and Interface are here to supports that.
• Since Class and Object are distinct concepts, Identity and  State are majors concerns. The dynamic languages are a mean to answer it (even if it is partially).