Re: Advantages of object-oriented programming

On 28 Oct 2006 12:50:28 GMT, ram@xxxxxxxxxxxxxxxxxx (Stefan Ram)
wrote:

"S Perryman" <a@xxxxx> writes:
Moreover, I do not know, what "identity of an object" means to you. [...]
What does it mean in the real world ??
Looking at identical siblings, identity is evidently something physical.

There is no such thing as "identity" in the object model.
Wittgenstein:

»Roughly speaking: to say of two things that they are
identical is nonsense, and to say of one thing that it is
identical with itself is to say nothing.«

http://www.kfs.org/~jonathan/witt/t55303en.html

The notion »identity« makes sense as soon as one considers
language: Here, it can be used to express that two (different)
noun phrases refer to the same entity of an object model.

If two twins had the same values of all their properties, this
would also include their spatial position, so they would be
one person. If they differ in some of their properties, it
would be misleading to call them "identical".
I think this is confusing instances with identity.

And in the software world, it appears to be a similar thing.
Something physical that distinguishes the fact that entities
have the same values, but are not the same thing.

I think the idea being discussed is valid, but not completely scoped
out.

The idea that an object has identity is true, but identity is not the
sole way we discern an object.

For myself, I have found over the years that using the mechanism I
think first stated by Booch to be the most ideal - although I have
extended it.

"An object has identity, state and action". Where identity is its
name, state is the sum of the values of its attributes and action is
described in the form of its methods. An objects type is the sum of
its identity, state and action. This is different from the
programatical concept of type. (this allows for the separation of
instance and identity).

I have extended that to define an object to be the above and also to
be a 'tangible real world thing'. That is, it must exist as an
object in the real world. This to me is the most important concept in
OO.

I've found that doing this forces one to then consider the case of
other concepts such as abstractions, classes, interfaces and the
like which often get ignored by programmers and are equally, if not
more important than objects themselves. It also forces one to think
about what to do with things in the programming world that dont meet
the criteria of being called objects.

I've also found that this concept removes the need to focus on
language symantics (which a true OO person would never do in my book)
and focus on the concepts and ideas being expressed which I think is
more impotant.

An example, I might have a set of routines that perform tasks on some
data. I might organise these routines so that the ones that are
related go in a class. This class doesnt describe an object (it lacks
tangibility and most likely state), an instance of the class isnt an
object. I call this entity a 'service' - exactly how it is called in
the real world. Stored procedures in a relational database would be a
classic example of services.

Likewise, it is possible to have a set of values (data) that also can
be organised and put in a class (in the old C days, we would use a
struct). Again, an instance of this data entity is still not an
object (it lacks action and tangibility). I call this entity a mixin
(because its usually mixed in with services ). A data row (not
normalised) in a relational database table would be a classic example
of a mixin.

You can combine services and mixins together (one usually acts on the
other), the result is still not an object (no tangibility still).

Note: Objects themselves may use or contain services and mixins both
internally and/or externally to perform many of their tasks. In the
same way that the local high street ATM machine has hidden mechanisms
inside to perform its functionality. A good way of thinking of it is
this: A butler is a person (object) that performs a set of services.
These services may or may not require separate information (mixins) to
be performed.

Note: When I say contain, I dont mean programatically such as an
protected set of methods. The methods (functions) that make up the
service are defined in the external service layer. From a
programatical view, one uses interfaces. In this way, the services can
be shared - such that the pizza delivery person may also perform the
butlers services. By the word 'contained' it is meant encapsulation -
such that the interface used is not exposed to entities outside the
object. One has to send the object the appropriate message asking for
a service to be performed. If its the wrong object, one will get a
pizza rather than ones suit cleaned.

So what I now do in my program architectures is to use the OSI layered
model in with the concept of frameworks to produce an architecture
from the ground up that works as follows:

Presentation Layer.
Application Layer
Object Layer
Application Framework Layer
Service Layer

Over the decades, I have found this model to be most suitable for most
environments, if I am not writing OO software, I can leave out the
Object layer and carry on. Neither is it language specific. One can
do OO in assembler, C and even COBOL (ok it gets a little hard in say
COBOL 87 or earlier).

Just my thoughts.
Andy

.

Relevant Pages

  • Re: Advantages of object-oriented programming
    ... like which often get ignored by programmers and are equally, ... object (it lacks action and tangibility). ... You can combine services and mixins together (one usually acts on the ... Presentation Layer. ...
    (comp.object)
  • Re: What will many cores mean to future Windows releases?
    ... Or if you don't like the view analogy one might think about an OPF an another sort of 'VM'--let the programmer write myObj.Save and an entire underlying layer is invoked. ... The programmers must concentrate on their human problem, ... In fact, these aren't VM anymore but, as you stated, JIT compilers. ... The gap between the best software engineering practice ...
    (borland.public.delphi.non-technical)
  • Re: What will many cores mean to future Windows releases?
    ... viewing on joins that are normal operational processes. ... programmers in a box and retard their learning? ... I've generally heard it said that a programmer should be competent one layer ... On the general issue of programmer competence, ...
    (borland.public.delphi.non-technical)