From: H. S. Lahman on
Responding to Kazakov...

>>>>As I illustrated in the Car example a couple of messages ago, A Drive
>>>>Train is not a Car by any stretch of the imagination. They are quite
>>>>different things and they share no properties. There is no relation
>>>>between their types; there is only a logical association between objects.
>>>
>>>
>>>You didn't say *what* you wanted to delegate and how this managed to stay
>>>not shared.
>>
>>In the original examples,
>>
>><examples>
>>In some problem context I may have a notion of Car. That Car will have
>>a drive train in the problem space. But if my problem context doesn't
>>need to know anything special about the drive train (e.g., the
>>application in an inventory control program), I can abstract the notion
>>of a drive train as simply properties of a [Car] abstraction
>>(horsepower, fuel consumption, etc.) without any delegation of
>>generalization.
>>
>>OTOH, if my problem space is an auto assembly plant, the drive Train
>>exists independently of the Car until it is incorporated in the
>>assembly. So I need to model the Drive Train as an object independent
>>of Car that becomes a component of a Car. But the Drive Train is not a
>>Car in that context by any stretch of the imagination so no
>>generalization relations exists between them. All one has is a simple
>>conditional association between peer objects.
>></examples>
>>
>>The first paragraph represents Car without delegation while Drive Train
>>is clearly delegated from Car in the second paragraph. When that
>>delegation is abstracted all the properties (horsepower, fuel
>>consumption, etc.) that are related to a drive train are removed from
>>Car and allocated to the Drive Train object. There is no longer any
>>shared semantics; Car and Drive Train only have an association to
>>determine which members of their respective sets may collaborate.
>
>
> This still does not answer the question: what does Car delegate to Drive
> Train?

All the properties that are logically related to a Drive Train. Without
delegation the Car has properties like 'horsepower' because it has a
drive train at that level of abstraction. After the delegation only
Drive Train has such properties.

>
> And "semantics" is not something you could "store", "allocate", "keep" etc.
> Semantics is a relation between signs and what they represent. If a car
> represents a drive train, this does not necessary mean that it physically
> is a drive train. Your representative in the Congress is not you, though
> you *delegated* to him some of your constitutional rights. When you
> exercise your rights through him, it does not mean that he lives in your
> home and wears your socks...

The problem here is fundamental OOA/D abstraction (or abstraction in
general, for that matter!). A 'car' is a physical entity in the problem
space that one needs to abstract. How one abstracts it depends on what
is important about it to the problem in hand.

A car doesn't represent a drive train in the problem space; it
physically has one _if all one needs to explicitly identify is a 'car'_.
If I represent the Car as an object without delegation, then I must
represent the relevant properties it has in the problem space, which
includes those of its drive train.

However, if I view the problem space at a lower level of abstraction
where a drive train is an independent, identifiable, standalone,
physical component of a car, then I have to abstract the the Drive Train
as an independent, identifiable, standalone object. At that point there
are no shared properties between them.

Nor, as a client, do you "exercise your rights through him". In the OO
paradigm, if you need to collaborate with a Drive Train, you navigate
relationships directly to it and collaborate on a peer-to-peer basis.
The fact that one of those relationships happens to be between Car and
Drive Train is irrelevant because navigating relationship paths is
orthogonal to the class semantics of the object along that path.

In fact, to "exercise your rights through him" you would have to include
the Drive Train interface in the Car interface. That would create an
unnecessary dependency of the Car abstraction on the Drive Train
abstraction. So when the Drive Train interface changed, then the Car
interface would also have to change. That's a major no-no in OO practice.

<aside>
To illustrate the point, consider the model:

[Mechanic]
| *
|
| R1
|
| is associated with
| 1
[Car]
| 1
| component of
|
| R2
|
| 1
[DriveTrain]

In some method of [Mechanic] that needs to deal with a DriveTrain, the
abstract action language (AAL) code use for UML OOA/D would look
something like:

ref = this -> R1 -> R2 // navigate relationships
GENERATE M1 ref ... // issue collaboration message

where 'M1' is a message identifier and '...' is whatever data one wants
to send with the message.

The important thing to note here relative to this thread is the
[Mechanic] method needs to know absolutely nothing about the semantics
of either [Car] or [DriveTrain] -- not even their class names! All it
relies on is that whoever is on the end of the relationship path will be
able to accept an 'M1' message (which is the developer's responsibility
to ensure).

The point here is that in OOA/D peer-to-peer collaboration is
institutionalized in terms of relationship navigation so that
collaboration is a personal matter between only the client and the
service. In fact, the relationship navigation is so abstract that full
code generators from UML models typically treat relationship
implementations as class-cutting aspects. IOW, most of the constraints
and conventions of the 3GL type systems are irrelevant.
</aside>

>
>
>>>>>>IOW, objects collaborate on a peer-to-peer basis.
>>>>>
>>>>>OK, that's the same disagreement between us. There is no peers at the
>>>>>abstraction level of types. You won't get me back down to the ad-hockery of
>>>>>individual objects... (:-))
>>>>
>>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse
>>>>to accept the most fundamental tenets of OOA/D?
>>>
>>>As I said, we have different views on what OO is. This includes A/D.
>>
>>An interesting Freudian Typo (A/D vs. OOA/D). B-)
>
>
From: Dmitry A. Kazakov on
On Tue, 05 Sep 2006 15:34:10 GMT, H. S. Lahman wrote:

> Responding to Kazakov...
>
>> This still does not answer the question: what does Car delegate to Drive
>> Train?
>
> All the properties that are logically related to a Drive Train. Without
> delegation the Car has properties like 'horsepower' because it has a
> drive train at that level of abstraction. After the delegation only
> Drive Train has such properties.

= car has delegated implementation of these properties to a drive train.
Such properties are still exposed in the car's interface. They are of the
car, while the act of delegation is merely an implementation detail.

>> And "semantics" is not something you could "store", "allocate", "keep" etc.
>> Semantics is a relation between signs and what they represent. If a car
>> represents a drive train, this does not necessary mean that it physically
>> is a drive train. Your representative in the Congress is not you, though
>> you *delegated* to him some of your constitutional rights. When you
>> exercise your rights through him, it does not mean that he lives in your
>> home and wears your socks...
>
> The problem here is fundamental OOA/D abstraction (or abstraction in
> general, for that matter!). A 'car' is a physical entity in the problem
> space that one needs to abstract. How one abstracts it depends on what
> is important about it to the problem in hand.
>
> A car doesn't represent a drive train in the problem space; it
> physically has one _if all one needs to explicitly identify is a 'car'_.
> If I represent the Car as an object without delegation, then I must
> represent the relevant properties it has in the problem space, which
> includes those of its drive train.

Properties of a car are independent on whether computerized models of those
are delegated or not. A car from the problem space delegates nothing. It is
absurd to think otherwise, provided, we aren't going to fall into OO
religion, claiming that physical world is OO.

[...]
> In fact, to "exercise your rights through him" you would have to include
> the Drive Train interface in the Car interface.

Sure. Otherwise, delegation would be an implementation detail. Anything not
exposed in the interfaces just does not exist. Your examples illustrate
low-level implementation details.

[example skipped]

>>>>>>>IOW, objects collaborate on a peer-to-peer basis.
>>>>>>
>>>>>>OK, that's the same disagreement between us. There is no peers at the
>>>>>>abstraction level of types. You won't get me back down to the ad-hockery of
>>>>>>individual objects... (:-))
>>>>>
>>>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse
>>>>>to accept the most fundamental tenets of OOA/D?
>>>>
>>>>As I said, we have different views on what OO is. This includes A/D.
>>>
>>>An interesting Freudian Typo (A/D vs. OOA/D). B-)
>>
>> It was not a typo, I intentionally used it without OO. Not all A/D is OO,
>> and OO is not exclusively about A/D.
>
> Ok, then my original question still stands: if your A/D is not OOA/D,
> then what are you doing on a forum like comp.object?

Are you sure that this forum follows your orthodoxy? (:-)) Even if it did,
I enjoy opinions different from mine.

>>>IMO, whatever you
>>>are doing for A/D clearly isn't OOA/D. That's because you can't do
>>>OOA/D if you restrict your thinking to types. One can make a strong
>>>case for the assertion that the evolution of OOA/D since Smalltalk was
>>>driven in no small part by the need to avoid the foot-shooting that
>>>became apparent when people actually started using the OOPL type systems.
>>>
>>>Types represent a major compromise with hardware models (e.g., explicit
>>>support of procedural message passing). As a result those compromises
>>>make it very easy to overlay procedural design techniques onto the
>>>OOPLs. They also have nasty side effects like physical coupling.
>>>Proper OOA/D is required to ensure that those compromises don't
>>>introduce problems like hierarchical dependencies and physical coupling.
>>
>> Types don't restrict anything. They just cannot do that, because type is an
>> abstraction. [ Proof: make each object singleton. q.e.d. ]
>
> They don't restrict anything?????? You have to be pulling my chain here.
>
> Tell that to all the OOP programmers who spend a substantial part of
> their time doing dependency management refactoring _after the
> application is demonstrated to work correctly_. All they are doing is
> overcoming the shortcomings of the OOPLs in order to make the
> application more maintainable. One doesn't have that problem with
> executable OOA/D models; when they execute correctly, they are done.

They do it for the sake of re-use. Models based on individual objects have
no validity beyond their direct application purpose. Cars are designed to
go into production.

People want to learn. Refactoring (largely based on the type system) is a
cognition process of software construction. It is programming as a
scientific activity.

>> Since you have returned to the core of our disagreement. I repeat the point
>> I made in our previous discussions. "Peer-to-peer collaboration" is the
>> *lowest* possible abstraction level. You could claim that logging is a peer
>> to peer collaboration between an axe and a tree, but that would impress
>> nobody. The problem at hand is to deal with forests and cubic kilometers of
>> wood. It is a way different level.
>
> But in an OO application the Axe does collaborate with an individual
> Tree directly rather than through a Forest. But the real problem here
> is that you are mixing levels of abstraction; forests and logging are at
> a quite different level of abstraction than an individual logger and an
> individual tree.

I didn't mix them, I illustrated you a real difference in abstraction
levels. The difference is between individual and common. An individual car
in car construction is as uninteresting as an individual tree for logging.
Their individualities are irrelevant as long as they do not clash with the
commonalities. Type is a tool to deal with such things. If UML will ever
evolve in something decent, it will become types as well. These types will
have diagrams as values and operations defined on diagrams. You can't get
rid of types.

--
Regards,
Dmitry A. Kazakov
http://www.dmit
From: ulf on
Stefan Ram wrote:
> ulf(a)cs.mun.ca writes:
> >... the original OO paradigm(s) of
> >Jacobson/Meyer/Booch/Rumbaugh in the 1990s, where client-server
> >relationships played a major role.
>
> If you consider 1990s work "original", how do you label
> the 1977 work of Hewitt ... or the 1967 work of Kay ...

My appologies.

Originally I intended to mention also the more early development of the
OO idea around OO PLs, including Simula, ST, Self, Loops... But since
my point was to contrast Mr Lahman's depiction of what "the OO
paradigm", and Mr Lahman has an issue with "3GLs", I then decided to
skip them and focus on the OO methods of the named OO "gurus".

Ulf Sch√ľnemann

From: S Perryman on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
news:10kl5qhtitkv5.56sgxn4719cu$.dlg(a)40tude.net...

> On Tue, 05 Sep 2006 15:34:10 GMT, H. S. Lahman wrote:

>> Responding to Kazakov...

>>>>Types represent a major compromise with hardware models (e.g., explicit
>>>>support of procedural message passing). As a result those compromises
>>>>make it very easy to overlay procedural design techniques onto the
>>>>OOPLs. They also have nasty side effects like physical coupling.
>>>>Proper OOA/D is required to ensure that those compromises don't
>>>>introduce problems like hierarchical dependencies and physical coupling.

>>> Types don't restrict anything. They just cannot do that, because type is
>>> an
>>> abstraction. [ Proof: make each object singleton. q.e.d. ]

>> They don't restrict anything?????? You have to be pulling my chain here.

Given that type theory is based on mathematics, what "major compromise"
or 'restriction' does mathematics ever make/do with anything (think of the
Halting problem, Russells' Paradox etc) ?? :-)

So the initial claim shows a degree of ignorance.
Specifically, being unable to separate a theory from the practical use of
that theory.


>> Tell that to all the OOP programmers who spend a substantial part of
>> their time doing dependency management refactoring _after the
>> application is demonstrated to work correctly_. All they are doing is
>> overcoming the shortcomings of the OOPLs in order to make the
>> application more maintainable.

Another initial claim showing quite a degree of ignorance.
It is not types, or type theory in general, that cause these problems or
work, but
the use in OOP of one particular type regime (one that has seen better days)
..

To use an analogy, it is like having mathematics and claiming maths is
difficult because, although multiplication (x *y) is defined, some regime
forces
me to write it as x + x + x + ... (y times) .


>> One doesn't have that problem with
>> executable OOA/D models; when they execute correctly, they are done.

> They do it for the sake of re-use. Models based on individual objects have
> no validity beyond their direct application purpose. Cars are designed to
> go
> into production.

That much is true.
I and colleagues have certainly seen enough Shlaer-Mellor projects in the
telecoms sector where the 'models' are not reusable beyond their original
reason for conception.


> People want to learn. Refactoring (largely based on the type system) is a
> cognition process of software construction. It is programming as a
> scientific activity.

I don't restructure industry systems merely for learning (I have better
things to
do with my time) . :-)


Regards,
Steven Perryman


From: H. S. Lahman on
Responding to Kazakov...

>>>This still does not answer the question: what does Car delegate to Drive
>>>Train?
>>
>>All the properties that are logically related to a Drive Train. Without
>>delegation the Car has properties like 'horsepower' because it has a
>>drive train at that level of abstraction. After the delegation only
>>Drive Train has such properties.
>
>
> = car has delegated implementation of these properties to a drive train.
> Such properties are still exposed in the car's interface. They are of the
> car, while the act of delegation is merely an implementation detail.

Not at all. The delegation is essentially just a shift in the level of
abstraction when viewing the problem space. At a higher level of
abstraction the only identifiable entity to abstract is a 'car'. At a
lower level of abstraction one has multiple identifiable entities to
abstract, like 'drive train'. Those entities are logically related in
the problem space but they are not the same entities at all at that
level of abstraction.

>>>And "semantics" is not something you could "store", "allocate", "keep" etc.
>>>Semantics is a relation between signs and what they represent. If a car
>>>represents a drive train, this does not necessary mean that it physically
>>>is a drive train. Your representative in the Congress is not you, though
>>>you *delegated* to him some of your constitutional rights. When you
>>>exercise your rights through him, it does not mean that he lives in your
>>>home and wears your socks...
>>
>>The problem here is fundamental OOA/D abstraction (or abstraction in
>>general, for that matter!). A 'car' is a physical entity in the problem
>>space that one needs to abstract. How one abstracts it depends on what
>>is important about it to the problem in hand.
>>
>>A car doesn't represent a drive train in the problem space; it
>>physically has one _if all one needs to explicitly identify is a 'car'_.
>> If I represent the Car as an object without delegation, then I must
>>represent the relevant properties it has in the problem space, which
>>includes those of its drive train.
>
>
> Properties of a car are independent on whether computerized models of those
> are delegated or not. A car from the problem space delegates nothing. It is
> absurd to think otherwise, provided, we aren't going to fall into OO
> religion, claiming that physical world is OO.

To an auto retailer the drive train is an integral part of the notion of
'car' and there is no distinction between them. To the manager of an
auto assembly plant the 'drive train' is a completely independent entity
whose properties have nothing at all to do with the notion of 'car'.
IOW, the manager views 'car' as simply a collection of discrete parts
and would never dream of thinking that a 'drive train' is-a 'car'.

Therefore the notion of what a 'car' is and what properties it has is
very strongly dependent on the context of the problem in hand. IOW,
properties are dependent on the conceptual context of the problem. We
abstract the entities that are identifiable in the problem space at a
level of abstraction that is appropriate to the problem in hand. We
abstract them as independent because the delegation occurred when we
chose the level of abstraction of the problem space view that rendered
them independent.

You can represent whatever delegations you want at the OOP level, but
for the application to be well-formed in an OOA/D sense every object
/must/ be an abstraction of some uniquely identifiable entity in some
problem space. Moreover, that entity must have a unique set of
/intrinsic/ properties that are not found in other objects (unless a
true generalization exists in the problem space where "is-a" applies to
all the objects).

>
> [...]
>
>>In fact, to "exercise your rights through him" you would have to include
>>the Drive Train interface in the Car interface.
>
>
> Sure. Otherwise, delegation would be an implementation detail. Anything not
> exposed in the interfaces just does not exist. Your examples illustrate
> low-level implementation details.

And that is clearly wrong for a paradigm where the primary goal is
software maintainability. One wants to minimize the number of places
where changes must be made in the face of volatile requirements. So how
does the software developer consistently avoid unnecessary edits when
requirements change? By employing a fundamental DESIGN paradigm like
peer-to-peer collaboration up front in the original design. So there is
no "low level implementation" involved at all; it is basic OOA/D.

>>>>>>>>IOW, objects collaborate on a peer-to-peer basis.
>>>>>>>
>>>>>>>OK, that's the same disagreement between us. There is no peers at the
>>>>>>>abstraction level of types. You won't get me back down to the ad-hockery of
>>>>>>>individual objects... (:-))
>>>>>>
>>>>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse
>>>>>>to accept the most fundamental tenets of OOA/D?
>>>>>
>>>>>As I said, we have different views on what OO is. This includes A/D.
>>>>
>>>>An interesting Freudian Typo (A/D vs. OOA/D). B-)
>>>
>>>It was not a typo, I intentionally used it without OO. Not all A/D is OO,
>>>and OO is not exclusively about A/D.
>>
>>Ok, then my original question still stands: if your A/D is not OOA/D,
>>then what are you doing on a forum like comp.object?
>
>
> Are you sure that this forum follows your orthodoxy? (:-)) Even if it did,
> I enjoy opinions different from mine.

The forum membership is not at issue. The forum subject matter is OOA/D
(OOP is addressed by comp.object.programming). Every OOA/D author
presenting a basic, general purpose methodology for OOA/D that I have
ever read advocates peer-to-peer collaboration.

>>>>IMO, whatever you
>>>>are doing for A/D clearly isn't OOA/D. That's because you can't do
>>>>OOA/D if you restrict your thinking to types. One can make a strong
>>>>case for the assertion that the evolution of OOA/D since Smalltalk was
>>>>driven in no small part by the need to avoid the foot-shooting that
>>>>became apparent when people actually started using the OOPL type systems.
>>>>
>>>>Types represent a major compromise with hardware models (e.g., explicit
>>>>support of procedural message passing). As a result those compromises
>>>>make i