GOF State Pattern without fully shared interface

Responding to Coates...

>>Therefore the Client should always navigate to [State] through [Context]
>>and collaborate with State in a peer-to-peer fashion rather than using
>>the [Context] interface as a middleman. Peer-to-peer navigation is also
>>fundamental to the OO paradigm because it is the main way one eliminates
>>the hierarchical dependencies of functional decomposition. IOW, the
>>interface of [Context] should not have any of the State responsibilities
>>after the delegation.
>
>
> Note, fundamental to Lahman's OO paradigm. The evaluation of using
> peer to peer communication for roughly 4 or more nodes, each capable
> of 4 or more message, by most programming and other system building
> experts in nearly every paradigm, OO or not, is that relying upon it
> often results in a nightmare, web of intractable complexity. Much
> better to rely upon the intermediary node paradigm messaging
> demonstrated by GoF in numerous patterns like State, Context,
> Observer, Mediator, etc..

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?

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.

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.


*************
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 27 Apr, 17:28, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
> Responding to Coates...
>
>
>
>
>
> >>Therefore the Client should always navigate to [State] through [Context]
> >>and collaborate with State in a peer-to-peer fashion rather than using
> >>the [Context] interface as a middleman. Peer-to-peer navigation is also
> >>fundamental to the OO paradigm because it is the main way one eliminates
> >>the hierarchical dependencies of functional decomposition. IOW, the
> >>interface of [Context] should not have any of the State responsibilities
> >>after the delegation.
>
> > Note, fundamental to Lahman's OO paradigm. The evaluation of using
> > peer to peer communication for roughly 4 or more nodes, each capable
> > of 4 or more message, by most programming and other system building
> > experts in nearly every paradigm, OO or not, is that relying upon it
> > often results in a nightmare, web of intractable complexity. Much
> > better to rely upon the intermediary node paradigm messaging
> > demonstrated by GoF in numerous patterns like State, Context,
> > Observer, Mediator, etc..
>
> 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?
>

The second point is unrelated to the first, and highly
subjective......you are the only one I know of that claims "peer-to-
peer collaboration is .. fundamental to OO development"....it appears
to be a recipe for a nightmare of flatland complexity..

> 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.
>
> 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.
>
> *************
> 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- Hide quoted text -
>
> - Show quoted text -

Responding to Nicholls...

>>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?
>>
>
>
> The second point is unrelated to the first, and highly
> subjective......you are the only one I know of that claims "peer-to-
> peer collaboration is .. fundamental to OO development"....it appears
> to be a recipe for a nightmare of flatland complexity..

I take it you accept the second point. So how does one eliminate
hierarchical dependencies in functional decomposition trees?

One way is to avoid reuse of higher level nodes in different contexts so
that the tree remains a tree rather than becoming a lattice. But that
leads to incredible duplication of limbs, which was recognized as bad
long before Structured Programming.

Another way is to flatten the tree so that the leaf nodes communicate on
a peer-to-peer basis as indivisible units. In a functional decomposition
that becomes enormously tedious because the leaf nodes are indivisible
at the level of 3GL operators, as you point out.

However, one can /also/ introduce a notion of flexible logical
indivisibility, as the OO paradigm does. Then one can define the
application at different levels of abstraction: subsystems, objects, and
responsibilities where each is logically indivisible at its level of
abstraction. That also allows the subsystems to be organized by level of
abstraction so that the objects that abstract different subsystems are
logically indivisible at different levels of abstraction.

Throw in things like encapsulation, implementation hiding, separation of
message and method, and problem space abstraction for invariant
structure and one has a very useful approach to managing complexity
without hierarchical dependencies. So one can make a very strong case
that the three primary features that distinguish the OO paradigm from
other development paradigms are: problem space abstraction, flexible
logical indivisibility, and peer-to-peer collaboration.


*************
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

There is a danger we'll revisit old ground....so I'm going to be
rather agressive with my snipping...feel free to unsnip.....I have
never witnesses non hierachical dependencies yet.....I personally
believe it to be a mirage.

but specifically

> However, one can /also/ introduce a notion of flexible logical
> indivisibility, as the OO paradigm does.

have you got a reference for this?

>Then one can define the
> application at different levels of abstraction: subsystems, objects, and
> responsibilities where each is logically indivisible at its level of
> abstraction. That also allows the subsystems to be organized by level of
> abstraction so that the objects that abstract different subsystems are
> logically indivisible at different levels of abstraction.

are (can) these subsystems (be) nested?

Responding to Nicholls...

> There is a danger we'll revisit old ground....so I'm going to be
> rather agressive with my snipping...feel free to unsnip.....I have
> never witnesses non hierachical dependencies yet.....I personally
> believe it to be a mirage.

If you have been witnessing well-formed OO applications, eliminating
dependencies in general is the point so not observing them would be a
demonstration of correct methodology. B-)

I assume what you mean is that all dependencies are hierarchical. I
think that is only true if one regards generic DbC contracts as
hierarchical. At best that is a quite different sort of dependency than
the thread context.

>>However, one can /also/ introduce a notion of flexible logical
>>indivisibility, as the OO paradigm does.
>
>
> have you got a reference for this?

That's like asking if one has a reference to problem space abstraction.
When I abstract the notion of a Car from the problem space, do I
abstract it with a single object or as multiple objects including Wheels
and whatnot? I will make that choice based upon what specific problem I
am solving. But that choice is specifying what logical indivisibility is
for that context.

Also note that a subsystem is clearly defined at a higher level of
abstraction than the objects that implement it. What an object is and
its role in the problem solution is clearly defined at a higher level of
abstraction than its individual responsibilities.

At a systems engineering level subsystems are defined at a particular
level of abstraction so that their client/service relationships can be
organized into a directed, acyclic graph based on the level of
abstraction of the services. Since the subsystems can be at different
levels of abstraction, that implies that their subject matters can be
implemented at different levels of abstraction. Each level of
abstraction defines what logical indivisibility means for objects and
responsibilities in that context.

BTW, I once worked with an application where a single scalar attribute
ADT in a higher level subsystem was expanded in a lower level service
subsystem into about a dozen classes with thousands of objects and a
total of about 10**9 individual data elements. That may be an extreme
example but that sort of flexible logical indivisibility is very common
in OO applications.

>>Then one can define the
>>application at different levels of abstraction: subsystems, objects, and
>>responsibilities where each is logically indivisible at its level of
>>abstraction. That also allows the subsystems to be organized by level of
>>abstraction so that the objects that abstract different subsystems are
>>logically indivisible at different levels of abstraction.
>
>
> are (can) these subsystems (be) nested?

Yes, but usually only in terms of systems engineering functional
decomposition. That is, only leaf subsystems can be implemented with
objects and higher level subsystems can only contain subsystems. As I
mentioned above, even that nesting is limited to a DAG so the nesting
decomposition cannot be turned into a lattice.

As it happens the translation OO methodologies do the best job of
merging systems engineering with application development. In those
methodologies nesting of subsystems is usually not a logical
relationship. It is usually a project management overlay for allocating
development resources and the DAG of client/service relationships
applies only to the leaf subsystems.

Corollary: when a leaf subsystem ends up being too large to develop as a
unit it is typically broken up into distinct subsystems. The way one
does that is formally based on level of abstraction (i.e., one subsystem
for high level control and one or more subsystems to provide detailed
services to it).


*************
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 Apr 27, 12:28 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:

> Elliott wrote:
> >
> > Lahman wrote:
> >>Therefore the Client should always navigate to [State] through [Context]
> >>and collaborate with State in a peer-to-peer fashion rather than using
> >>the [Context] interface as a middleman. Peer-to-peer navigation is also
> >>fundamental to the OO paradigm because it is the main way one eliminates
> >>the hierarchical dependencies of functional decomposition. IOW, the
> >>interface of [Context] should not have any of the State responsibilities
> >>after the delegation.

> > Note, fundamental to Lahman's OO paradigm. The evaluation of using
> > peer to peer communication for roughly 4 or more nodes, each capable
> > of 4 or more message, by most programming and other system building
> > experts in nearly every paradigm, OO or not, is that relying upon it
> > often results in a nightmare, web of intractable complexity. Much
> > better to rely upon the intermediary node paradigm messaging
> > demonstrated by GoF in numerous patterns like State, Context,
> > Observer, Mediator, etc..

> 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.)

> 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.

> 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....

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

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.

On 1 May, 11:48, Mark Nicholls <Nicholls.M...{}mtvne.com> 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 lied...I typed it in wrong....slightly worrying is that the first
reference is from a certain HS Lahman.

>
> 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.

On 1 May, 11:52, Mark Nicholls <Nicholls.M...{}mtvne.com> wrote:
> On 1 May, 11:48, Mark Nicholls <Nicholls.M...{}mtvne.com> 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 lied...I typed it in wrong....slightly worrying is that the first
> reference is from a certain HS Lahman.
>
>

I have found 9 references to the phrase in google....

All are by you......

If this concept is central to OO, then why is it that only you are
saying this, you may be right, but unless I can understand it then to
me it seems to be a contradiction in terms....i.e. something that is
indivisible would seem to be inflexible.

>
>
>
> > 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.- Hide quoted text -
>
> - Show quoted text -

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) .

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.

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