Re: Client/Service relationships & Flow of Requirements.

On Wed, 31 Jan 2007 14:26:28 GMT, "Daniel T." <daniel_t@xxxxxxxxxxxxx>
wrote:

"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote:
Responding to Daniel T....

However, I changed my tune when I started using messages to inform an
object of external conditions, rather than using it to produce wanted
output. Then I ended up with a service that has methods which must be
called when particular external conditions are met. That's something
that doesn't fit well with DbC nor with HS' remarks. When using messages
in this way, changes in the service can force client changes.

I don't see why there would be a problem. [Of course I use object state
machines for /all/ behavior responsibilities so my behaviors are
/always/ triggered by events announcing changes in external conditions.
B-)] Do you have an example that demonstrates the problem?

The basic assumption in the "client owns the interface" principle is
that the client needs the service to perform some action on its behalf.
Obviously the client must be able to inform the service when to perform
that action, so the client gets to add methods to the interface
describing the services it needs. However, when messages are used to
inform, rather than compel, the onus is on the message sender to do the
informing.

The predator/prey example can serve to illustrate what I mean:

The following is designed to compel Prey objects to do something:

class Prey:
def runFrom( predator ):
require: predator < 100 yards from prey
ensure: predator > 100 yards from prey

Whatever code sends the "runFrom" message to prey objects, it expects a
particular result, it is specifically sending the message so that the
prey will move away from the predator. (I.E., to cause the state to
change such that the predator and prey are more than 100 yards away from
each-other.) There is no requirement on the client to send the "runFrom"
message if the client doesn't want the prey object to move.

However, if the message is designed to inform rather than compel:

class Prey:
def predatorWithin100yards( predator ):
require: n/a
ensure: n/a

Now, the contract (which can't be stated properly in either the require
or ensure clause) is that anytime a predator is within 100 yards of the
prey object, it shall be informed of that fact. The onus is on the
client to do the right thing. The Prey object need not do anything at
all in response to the message.

Sorry, just to go off on an tangent here (and the following is just
off the top of my head without any real thought)


Consider the structure

class Location: << Mixin>>
x, y, z etc.

class AnimalLocations: << service>>
Locations
CompareLocations
registerObjects

class Animal: << abstract >>
Location
UpdateLocation
detectOtherAnimal

class Preditor : Animal <<concrete abstract>>
sneak, run, pounce, lookforprey

class Prey : Animal <<concrete abstract>>
hide, flee, keepwatchforpreditor


KnightOfCamelot : prey <object>
KillerBunnyOfCaerBannog : Preditor <<object>>

animalLocations.registerObjects( KightOfCamelot,
KillerBunnyOfCaerBannog)


What happens is that in the concurrent model, every animal has a
location. Those locations could be registered in an observable entity
(animal locations). When an animal moves, it needs to publish its new
location [updateLocation].

As each animal moves, it also checks the new location to see if there
is another animal near [DetectOtherAnimal/CompareLocations]. It would
then check to see what type of animal to see if needed to flee or
pounce etc.

Because each animal should be doing this check at the same time, it
becomes a concurrent application. There are different
implementations, thread per animal, thread for service methods etc
(but I am not up to play on concurrent development these days).

The idea behind this example was to try to demonstrate the removal of
messaging and the ability for an object to implement its own
behaviour.


Andy

.

Relevant Pages

  • Re: Client/Service relationships & Flow of Requirements.
    ... the client calls "foo" when it wants "bar" to return a particular value. ... The following is designed to compel Prey objects to do something: ... predator < 100 yards from prey ... It is the expectation of the response that makes the runFrom name immediately suspect in an OO context. ...
    (comp.object)
  • Re: Client/Service relationships & Flow of Requirements.
    ... The client is manipulating the service's state. ... The following is designed to compel Prey objects to do something: ... predator < 100 yards from prey ... not do anything at all in response to the message. ...
    (comp.object)
  • Re: Client/Service relationships & Flow of Requirements.
    ... Obviously the client must be able to inform the service when to perform that action, so the client gets to add methods to the interface describing the services it needs. ... The following is designed to compel Prey objects to do something: ... predator < 100 yards from prey ... Similarly, the Prey has a responsibility to react to the message, which is described by the DbC postcondition for the Prey's response to the message. ...
    (comp.object)
  • Re: Client/Service relationships & Flow of Requirements.
    ... called when particular external conditions are met. ... The basic assumption in the "client owns the interface" principle is ... The following is designed to compel Prey objects to do something: ... predator < 100 yards from prey ...
    (comp.object)
  • Re: Assamite Clan Newsletter, January 2006
    ... the specific positive consequences of a milling predator don't constitute an advantage. ... Its forward-pressure is orthogonal to your loss of pool. ... And, I claimed that voters frequently screwed their prey even if they failed to win, which is the reason people hate them as predators. ... If you mean, you've won lots of games after a miller hammered your library severly and got it down to 10 cards WAY prematurely, I can't speak to that because I didn't see the games you're talking about. ...
    (rec.games.trading-cards.jyhad)