GOF State Pattern without fully shared interface

"Mark Nicholls" wrote:
> The problem as ever, is I don't recognise your description as being
> OO....I recognise it as a system with some entities labelled as
> 'objects', that seem to have some 'object' like properties...the lack
> of reference to any identifyable standard books almost makes life
> difficult....so we can't jump in the deep end.
>
> Please define flexible logical indivisibly....if I google it as a
> phrase I get nothing....not one reference....that makes life hard for
> me as the reader because I cannot refer to some sort of dictionary to
> work out what you mean.
>
> I accept OO has an effect on 'dependencies' but it a word bandied
> about this group all too easily...what sort of dependencies are you
> refering to...logical, phyical, static, run time...?
>
> I accept that 'peer to peer' collaboration is a valid form of
> collaboration....but not that it is central to OO....if it is, is
> anyone else claiming it also? is there a definition/text I can refer
> to? I also do not accept that it breaks dependencies in any way more
> significant that bog standard subtyping.

I don't know if this helps any, but one of the examples I've seen Mr.
Lahman give is the following:

A::method1(x):
temp = this.attr1 + x
temp = Bref.doIt(temp)
this.attr2 = temp / 5

Where A is a class and Bref is a reference A holds to an instance of B.
In the method above, 'A' uses the return value from the doIt method in
'B' to perform a calculation. 'A' isn't just collaborating 'peer to
peer' but is dependent on B in order to perform a calculation. So we
have a functional hierarchy in which 'A' depends on 'B'.

If we refactor the above to look like this:

A::mehod1(x)
temp = this.attr1 + x
Bref.doIt(temp)

A::method2(x)
this.attr2 = x / 5

The dependency has been broken. 'A' sends a message to 'B' via the doIt
method but doesn't care what 'B' does in response; this is a better
example of 'peer to peer' collaboration. The calculation that 'A'
originally performed in method1 has been factored out to method2. 'A' no
longer cares who invokes method2; it could be an instance of 'B' or
someone else.

Anyway, you can find the original post here:

http://groups.google.com/group/comp....98c9804?hl=en&

The 'peer to peer' concept is something that had me curious after an
exchange with Mr. Lahman a few days ago, so I googled on the term for
comp.object and ran across the above post.

Responding to Coates...

>>I don't understand your point. Are you arguing that peer-to-peer
>>collaboration is not fundamental to OO development? That the primary
>>goal of OO development is not to eliminate the hierarchical dependencies
>>of functional decomposition that led to Spaghetti Code?
>
>
> Honestly, in 20 years of using with and studying OO I have read/heard
> no one else, but you who claims that peer-to-peer collaboration is
> significant much less fundamental to what OO is about. To me from my
> experience the only thing absolutely essential to OO are classes
> instantiated as objects and their interaction. Of course there is
> quite often a need to substitute types and thus polymorphism is the
> neighbor and closest of buddy of classes and their objects. (I'm
> aware of the distinction between object based languages (like early
> Ada) without polymorphism versus what are actually called OOP
> languages that have polymorphism like SIMULA, but I'm speaking of
> overall the overall object modelling conceptual framework that is
> common to both object based and OOP languages.)

Pick up any book or survey paper on OOA/D and somewhere the author is
going to say three things: (1) messages are separate from methods; (2)
objects send messages to collaborate with other objects; and (3)
messages are addressed to objects that have the relevant
responsibilities for the collaboration. It seems to me that is a pretty
clear definition of peer-to-peer collaboration.

As a specific reference, just look at any UML Interaction Diagram. How
can one interpret that as anything other than connecting the solution's
flow of control dots with peer-to-peer messages? Since UML is the de
facto notation for OOA/D, it seems to me that provides an official
blessing of peer-to-peer collaboration.

>>Note that your example patterns are not relevant to those issues. They
>>represent a solution (delegation and polymorphic dispatch) to a quite
>>different problem where the dynamics of collaboration are too complex to
>>capture as a simple static relationship. Regardless of the structure
>>provided to manage the dynamic substitution, the client still needs to
>>collaborate with the service in a peer-to-peer manner.
>
>
> In my experience direct service to client communication is not
> considered peer to peer. Direct client to client or direct service to
> service communication would be peer to peer and in most cases you want
> any form of many to many communication (between the same or different
> types) to use an intermediary to reduce complexity.

I was using 'client' and 'service' here in the more generic OO or DbC
sense, not the IT client/server sense. I think here and below you are
referring to the way the problem space is abstracted rather than to the
details of object collaborations.

>>Thus in the OP's example, once the delegation is done TCPState owns the
>>open() responsibility, not TCPConnection. So a client needing to open a
>>TCP connection should collaborate directly with TCPState.open(),
>>regardless of how that behavior implementation is substituted under the
>>hood via polymorphic dispatch.
>
>
> I'm not saying there is never a place for peer to peer communication,
> but even then especially where there is a single medium, it often
> improves speed and robustness to have some kind of mediation process,
> witness Ethernet. Though nodes *on a subnet* talk directly each node
> must negotiate the right to speak. And inter subnet traffic use a
> bridges and on a larger scale there is a hierarchy of routers.
> Otherwise....

We are talking about object-to-object collaborations. If one decides to
abstract a Proxy object to own the network protocol and put it between
some application object and the network port, that is a design decision
for problem space abstraction. The issue here is how the objects
collaborate _once one decides who they are_. The application object will
collaborate with the Proxy object on a peer-to-peer basis and Proxy
object will collaborate with the network port object on a peer-to-peer
basis.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Responding to Nicholls...

> The problem as ever, is I don't recognise your description as being
> OO....I recognise it as a system with some entities labelled as
> 'objects', that seem to have some 'object' like properties...the lack
> of reference to any identifyable standard books almost makes life
> difficult....so we can't jump in the deep end.
>
> Please define flexible logical indivisibly....if I google it as a
> phrase I get nothing....not one reference....that makes life hard for
> me as the reader because I cannot refer to some sort of dictionary to
> work out what you mean.

I think you are quibbling about a terminology issue. I happen to feel
'flexible logical indivisibility' is a very descriptive term to describe
a complex interplay of basic OO ideas. Because it is a complex issue
other authors may refer to it differently. That is largely a matter of
exposition style. Thus few OOA/D authors explicitly talk about
normalizing a Class Model, yet every one of them defines a bunch of
rules and guidelines that result in normalization of the model when they
are applied.

I am also one of the few people who refers to subdividing an application
into large scale modules as 'application partitioning'. (Most people are
content to call it 'systems engineering'.) That doesn't change the fact
that application partitioning and problem space abstraction are both
done in a very disciplined manner in OO development. Nor does it mean
that my view of it is different than that of established OOA/D authors.

Thus every OOA/D author that I know of will agree with the following
assertions, regardless of how they individually describe how to abstract
problem spaces:

(1) An OOA/D model represents a software solution to a problem.

(2) In UML that model has different views. The views that deal with the
resolution of functional requirements are distinguished from views of
deployment, configuration management, etc. by being "logical" views
(i.e., they reflect the logic of the solution).

(3) Subsystems, objects, and responsibilities each represent indivisible
abstractions at some level of problem space abstraction. When the views
of these units is restricted to representations of the solution logic,
those views represent logically indivisible units.

(4) Since subsystems are defined at different levels of abstraction
within an application, the notion of what is logically indivisible is
flexible from one subsystem to another and from one application to another.

To put it another way, consider these class model fragments:

[Car]
+ VBN
+ color
+ wheelCount
+ wheelSize
....

versus

[Car]
+ VBN
+ color
....
| 1
|
| R1
|
| conveyed on
| *
[Wheel]
+ size

I challenge you to find an established OOA/D author that will disagree
that: (A) both models represent a logical view; (B) that the notion of
'car' in both models is an indivisible abstraction of some problem space
entity; and (C) that the notion of the indivisibility of a 'car' in the
two models is different. IOW, the models represent two different views
of logical indivisibility in the same problem space. Since each model
abstracts the same problem space, that clearly indicates the notion of
logical indivisibility is flexible in the OO paradigm when abstracting
problem spaces.

Note that by focusing on the terminology of logical indivisibility you
are deflecting from the original point of why peer-to-peer collaboration
is central to OO development. As I explained originally, peer-to-peer
collaboration if crucial to eliminating hierarchical dependencies only
when it works in conjunction with flexible logical indivisibility. It
doesn't matter what one calls them; they are still central to the way
the OO paradigm eliminates hierarchical dependencies.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On May 1, 1:42 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:

> Note that by focusing on the terminology of logical indivisibility you
> are deflecting from the original point of why peer-to-peer collaboration
> is central to OO development. As I explained originally, peer-to-peer
> collaboration if crucial to eliminating hierarchical dependencies

Why eliminate hierachy when hierarchy and intermediaries allow for
scalability?

Elliott

On May 1, 12:47 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:

> Universe wrote:
> > I'm not saying there is never a place for peer to peer communication,
> > but even then especially where there is a single medium, it often
> > improves speed and robustness to have some kind of mediation process,
> > witness Ethernet. Though nodes *on a subnet* talk directly each node
> > must negotiate the right to speak. And inter subnet traffic use a
> > bridges and on a larger scale there is a hierarchy of routers.
> > Otherwise....

> We are talking about object-to-object collaborations. If one decides to
> abstract a Proxy object to own the network protocol and put it between
> some application object and the network port, that is a design decision
> for problem space abstraction. The issue here is how the objects
> collaborate _once one decides who they are_. The application object will
> collaborate with the Proxy object on a peer-to-peer basis and Proxy
> object will collaborate with the network port object on a peer-to-peer
> basis.

Depending on the level of abstraction or kind of modularity involved
class objects may collaborate logically peer to peer, or collaborate
logically through higher level classes. I.e. objects behind a Facade
may cause a Facade to generate different messages for communication
outside of the Facade, but often use peer to peer comms to speak
logically within the Facade. And similarly depending on the level of
abstraction or kind of modularity involved class objects may
collaborate physically (implementation wise) peer to peer, or
collaborate implementation wise through higher level classes.
Examples of peer to peer logical collaboration using implementation
hierarchy are how objects communicate in the MS Windows and the
Smalltalk architectures by using an event driven message posting
system.

Elliott
---
The goal of OO is to model a domain as a machine in order to reduce
complexity.



level abstbut should not always collaborate physically, that is
implementation wise, on peer to peer basis especially when there are
large number of objects involved. But logically procedures in a
Structured program nearly always speak peer to peer, and use hierarchy
to facilitate implem

On 1 May, 19:02, Universe <universe353-goo...{}yahoo.com> wrote:
> On May 1, 1:42 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
>
> > Note that by focusing on the terminology of logical indivisibility you
> > are deflecting from the original point of why peer-to-peer collaboration
> > is central to OO development. As I explained originally, peer-to-peer
> > collaboration if crucial to eliminating hierarchical dependencies
>
> Why eliminate hierachy when hierarchy and intermediaries allow for
> scalability?
>
> Elliott

Exactly...the objective is *not* to eliminate the hierarchy but the be
able to build, extend and manipulate the hierarchy.

On 1 May, 14:14, "Leslie Sanford" <jabberdab...{}BiteMeHotmail.com>
wrote:
> "Mark Nicholls" wrote:
> > The problem as ever, is I don't recognise your description as being
> > OO....I recognise it as a system with some entities labelled as
> > 'objects', that seem to have some 'object' like properties...the lack
> > of reference to any identifyable standard books almost makes life
> > difficult....so we can't jump in the deep end.
>
> > Please define flexible logical indivisibly....if I google it as a
> > phrase I get nothing....not one reference....that makes life hard for
> > me as the reader because I cannot refer to some sort of dictionary to
> > work out what you mean.
>
> > I accept OO has an effect on 'dependencies' but it a word bandied
> > about this group all too easily...what sort of dependencies are you
> > refering to...logical, phyical, static, run time...?
>
> > I accept that 'peer to peer' collaboration is a valid form of
> > collaboration....but not that it is central to OO....if it is, is
> > anyone else claiming it also? is there a definition/text I can refer
> > to? I also do not accept that it breaks dependencies in any way more
> > significant that bog standard subtyping.
>
> I don't know if this helps any, but one of the examples I've seen Mr.
> Lahman give is the following:
>
> A::method1(x):
> temp = this.attr1 + x
> temp = Bref.doIt(temp)
> this.attr2 = temp / 5
>
> Where A is a class and Bref is a reference A holds to an instance of B.
> In the method above, 'A' uses the return value from the doIt method in
> 'B' to perform a calculation. 'A' isn't just collaborating 'peer to
> peer' but is dependent on B in order to perform a calculation. So we
> have a functional hierarchy in which 'A' depends on 'B'.
>
> If we refactor the above to look like this:
>
> A::mehod1(x)
> temp = this.attr1 + x
> Bref.doIt(temp)
>
> A::method2(x)
> this.attr2 = x / 5
>
> The dependency has been broken. 'A' sends a message to 'B' via the doIt
> method but doesn't care what 'B' does in response; this is a better
> example of 'peer to peer' collaboration. The calculation that 'A'
> originally performed in method1 has been factored out to method2. 'A' no
> longer cares who invokes method2; it could be an instance of 'B' or
> someone else.

OK....the client code is now dependent on A::method1 and
A::method2....the behaviour linking the 2 has moved to the
client....so the tree is flattened a little....but now lets do all the
other dependencies....

A::method1 is 'hierachically' dependent on int::+ and B::doit (and I
assume they are dependent on other things)....so lets move them to the
client code, on the premise that 'peer to peer collaborations are
central to the OO paradigm'....A::method2 is 'hierachically'
dependent int::/...so lets move those to the client code....now we
have (lets assume '=' is some language primitive).

client code...
temp = a.attr1 + x
temp = b.doIt(temp)
a.attr2 = temp / 5

look A has no dependencies! (well it does really it is dependent on
the type of att1 and att2)...but A now does absolutely nothing.
the client code has all the dependendencies and does everything.
We can recursively do the same with b::doit and it's dependencies.

Yes this is a valid way to manipulate the dependency tree but it is
not a sensible rule of contruction.....recursively applied it is
simply a recipe for no reuse, no decomposition, no dependencies and no
objects and 1 massive method (one could argue that really it should be
written in assembly because somehow there is a hierachical dependency
between the client code, the language primitives and the underlying
assembly code).

>
> Anyway, you can find the original post here:
>
> http://groups.google.com/group/comp....98c9804?hl=en&
>
> The 'peer to peer' concept is something that had me curious after an
> exchange with Mr. Lahman a few days ago, so I googled on the term for
> comp.object and ran across the above post.- Hide quoted text -
>
> - Show quoted text -

On 1 May, 12:11, ggro...{}bigfoot.com wrote:
> On May 1, 11:48 am, Mark Nicholls <Nicholls.M...{}mtvne.com> wrote:
>
> > I accept that 'peer to peer' collaboration is a valid form of
> > collaboration....but not that it is central to OO....if it is, is
> > anyone else claiming it also?
>
> All systems, regardless of the paradigm, are conceptually "peer to
> peer" .
> The concept of peer is that of a kindred entity (properties, rights
> etc) .

yep....Mr Lahman seems to take the concept a stage further....i.e
'delegation' to him is 'navigation' to us....

>
> In functional programming, a system is a set of functions invoking
> each other. In OOP, a system is a set of objects invoking each other.
> And so on.
>
> OTOH, the concept of *hierarchy* is purely *human* .
> Specifically, to define an *ordering* (for whatever means) among
> peers.
>
> A set of objects can be ordered into a hierarchy. So can a set of
> procedures.
>
> Therefore in systems development, the concepts of hierarchy and peer-
> to-peer,
> are orthogonal.

he seems to be saying that moving behaviour from server to client
changes the hierachy...which is correct....but then seems to claim
this is

a) central to OO
b) a sensible construction rule

>
> It is interesting that the Smalltalk progenitors wrote of OOP in terms
> of
> collaborating objects sending messages between each other etc. But
> colloboration
> is not a synonym (or any-nym AFAIK :-) ) for peer.
>
> All of which does explain quite well why you cannot find the
> definition claimed, within
> the documented OO knowledge base.
>


> Regards,
> Steven Perryman

On 1 May, 18:42, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
> Responding to Nicholls...
>
> > The problem as ever, is I don't recognise your description as being
> > OO....I recognise it as a system with some entities labelled as
> > 'objects', that seem to have some 'object' like properties...the lack
> > of reference to any identifyable standard books almost makes life
> > difficult....so we can't jump in the deep end.
>
> > Please define flexible logical indivisibly....if I google it as a
> > phrase I get nothing....not one reference....that makes life hard for
> > me as the reader because I cannot refer to some sort of dictionary to
> > work out what you mean.
>
> I think you are quibbling about a terminology issue. I happen to feel
> 'flexible logical indivisibility' is a very descriptive term to describe
> a complex interplay of basic OO ideas.

it is if I understand what it means....it's descriptive to you because
you've invented it.

> Because it is a complex issue
> other authors may refer to it differently. That is largely a matter of
> exposition style. Thus few OOA/D authors explicitly talk about
> normalizing a Class Model, yet every one of them defines a bunch of
> rules and guidelines that result in normalization of the model when they
> are applied.

But normalisation is a concept that is defined in mathematics....I
know what it means, I can see it applied to relational schemas and
class diagram....I can pull thousands of references from google about
it.

>
> I am also one of the few people who refers to subdividing an application
> into large scale modules as 'application partitioning'. (Most people are
> content to call it 'systems engineering'.)

there are 41,400 references in google to this term...I know of this
term and read it in books, the first defintion in google is weak but
gives some indication of what it means.

> That doesn't change the fact
> that application partitioning and problem space abstraction are both
> done in a very disciplined manner in OO development.

I understand these terms and can find countless references to
them...thus I understand sentences containing them....I do not
understand sentences that contain *undefined* terms.

I believe my aunt makes very nice snoozlepickle!.....don't you agree!

> Nor does it mean
> that my view of it is different than that of established OOA/D authors.

how can you possibly claim that when you can give no reference to this
term or synonym for it that can be found in any established
references....in fact in any references.

>
> Thus every OOA/D author that I know of will agree with the following
> assertions, regardless of how they individually describe how to abstract
> problem spaces:
>
> (1) An OOA/D model represents a software solution to a problem.

wishy washy, but fine.

>
> (2) In UML that model has different views. The views that deal with the
> resolution of functional requirements are distinguished from views of
> deployment, configuration management, etc. by being "logical" views
> (i.e., they reflect the logic of the solution).

fine UML has a specification, whether we like it or not...it exists
and is well defined...I understand it.

>
> (3) Subsystems, objects, and responsibilities each represent indivisible
> abstractions at some level of problem space abstraction. When the views
> of these units is restricted to representations of the solution logic,
> those views represent logically indivisible units.
>

yes I understand the concept of logically indivisible...i.e.
atomic.....but not *flexible* indivisibility.....it's either
indivisible .....or it isn't.


> (4) Since subsystems are defined at different levels of abstraction
> within an application, the notion of what is logically indivisible is
> flexible from one subsystem to another and from one application to another.
>

So is your 'flexible' indivisibity the notion that a system is
specified at one level can be decomposed (hierarchivally) into it's
constituent part?

If it is then I don't understand the claim about hierachies not
existing....your phrase would seem to describe the hierachy.


> To put it another way, consider these class model fragments:
>
> [Car]
> + VBN
> + color
> + wheelCount
> + wheelSize
> ...
>
> versus
>
> [Car]
> + VBN
> + color
> ...
> | 1
> |
> | R1
> |
> | conveyed on
> | *
> [Wheel]
> + size
>
> I challenge you to find an established OOA/D author that will disagree
> that: (A) both models represent a logical view;

I never claimed it didn't.....this is a 'topmind' ploy of challenging
me to defend an argument I have not made.

> (B) that the notion of
> 'car' in both models is an indivisible abstraction of some problem space
> entity;

It's specification is indivisble (in some sense)....

It's implementation is clealy divisble by it's attributes and methods.

> and (C) that the notion of the indivisibility of a 'car' in the
> two models is different.

correct, because from one perspective it is atomic, and the other it
isn't!

> IOW, the models represent two different views
> of logical indivisibility in the same problem space. Since each model
> abstracts the same problem space,

this is not clear at all....it is quite possible to abstract the car
in one problem space yet be completely ignorant whether the car is
conveyed on wheels or ski's.

Thus they would be abstractions of 2 problem spaces...the problem is
decomposed into 2 orthogonal problems....which is clearly simpler to
'solve' than 1 big one......it is the 'scientific process'.

The relationship between the implementation of car is thus dependent
on the specification of 'wheel' *not* the implementation of
wheel......recursively we can not see the an ordering that defined a
hierachy.

QED.

> that clearly indicates the notion of
> logical indivisibility is flexible in the OO paradigm when abstracting
> problem spaces.

OK...flexible is a bad word for me in this context....it would be like
claiming that the atomicity of the atom is flexible because we can
decompose it into constituent part....it is not 'flexible', I cannot
make atoms a bit less atomic, or it's decomposition into electrons etc
slightly less decomposed, the views are *discrete* and *orthogonal*
not continuous ...
>
> Note that by focusing on the terminology of logical indivisibility you
> are deflecting from the original point of why peer-to-peer collaboration
> is central to OO development.

If I don't understand what you are saying we cannot have a
converstation, I am not trying to be pedantic, just attempting to
comprehend.

> As I explained originally, peer-to-peer
> collaboration if crucial to eliminating hierarchical dependencies only
> when it works in conjunction with flexible logical indivisibility.

for me my apparent nit picking has been central. I know think that
'flexible logical indivisibiliy' is in fact another term for the
duality of an atomic specification and the hierarchical decomposition
into constituent parts.

> It
> doesn't matter what one calls them;

it does if noone understands what they mean.

> they are still central to the way
> the OO paradigm eliminates hierarchical dependencies.
>

but the phrase appears to be a synonym for "hierarchical
dependencies".....changing the syntax does not change the semantics.

> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> h...{}pathfindermda.com
> Pathfinder Solutionshttp://www.pathfindermda.com
> blog:http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> i...{}pathfindermda.com for your copy.
> Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH

Responding to Nicholls...

>>I don't know if this helps any, but one of the examples I've seen Mr.
>>Lahman give is the following:
>>
>>A::method1(x):
>> temp = this.attr1 + x
>> temp = Bref.doIt(temp)
>> this.attr2 = temp / 5
>>
>>Where A is a class and Bref is a reference A holds to an instance of B.
>>In the method above, 'A' uses the return value from the doIt method in
>>'B' to perform a calculation. 'A' isn't just collaborating 'peer to
>>peer' but is dependent on B in order to perform a calculation. So we
>>have a functional hierarchy in which 'A' depends on 'B'.
>>
>>If we refactor the above to look like this:
>>
>>A::mehod1(x)
>> temp = this.attr1 + x
>> Bref.doIt(temp)
>>
>>A::method2(x)
>> this.attr2 = x / 5
>>
>>The dependency has been broken. 'A' sends a message to 'B' via the doIt
>>method but doesn't care what 'B' does in response; this is a better
>>example of 'peer to peer' collaboration. The calculation that 'A'
>>originally performed in method1 has been factored out to method2. 'A' no
>>longer cares who invokes method2; it could be an instance of 'B' or
>>someone else.
>
>
> OK....the client code is now dependent on A::method1 and
> A::method2....the behaviour linking the 2 has moved to the
> client....so the tree is flattened a little....but now lets do all the
> other dependencies....

You are thinking is purely procedural terms, not OO terms. You are
assuming that the client has some expectation about what A does. The
reason message and method are separated in OOA/D development is so that
the messages that trigger collaborations can be announcements (I'm Done)
rather than procedural imperatives (Do This). That allows the message
sender to think only about what /it/ did and not care who responds to
the message or how they respond to it.

The point of this example is not about who is invoking A's
responsibilities. It is about A's implementation dependence on what
doIt() does in the first example. That dependence is broken in the
second example because A no longer depends upon what B does; the call to
Bref.doIt() is just a message that announces that A has modified attr1.

Another way to see this difference is to consider what happens when the
requirements change and attr2 must be modified at a different time in
the solution than when attr1 is modified to ensure consistency. In the
first example method1 would have to be written. In the second example A
does not need to be touched at all.

BTW, apropos of the current thread, that is also a direct manifestation
of logical indivisibility, which I believe was Sanford's point. In the
first example method1 is not logically indivisible. It has two distinct
responsibilities: updating attr1 and updating attr2. So when the timing
of those responsibilities changes, it requires surgery. In the second
example method1 and method2 are logically indivisible with respect to
the problem solution. It is that logical indivisibility in the second
example that enables a significant change to flow of control to be
implemented without touching A.

> A::method1 is 'hierachically' dependent on int::+ and B::doit (and I
> assume they are dependent on other things)....so lets move them to the
> client code, on the premise that 'peer to peer collaborations are
> central to the OO paradigm'....A::method2 is 'hierachically'
> dependent int::/...so lets move those to the client code....now we
> have (lets assume '=' is some language primitive).
>
> client code...
> temp = a.attr1 + x
> temp = b.doIt(temp)
> a.attr2 = temp / 5
>
> look A has no dependencies! (well it does really it is dependent on
> the type of att1 and att2)...but A now does absolutely nothing.
> the client code has all the dependendencies and does everything.
> We can recursively do the same with b::doit and it's dependencies.

But what is gained by doing this? You have only moved the dependency on
b.doIt() from A to the client. The point is to /eliminate/ the dependency.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH