Re: Client/Service relationships & Flow of Requirements.

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

- - - - -
If I add a compel type method to the Prey class, the client need not
call it unless the client wants the prey to do what the method compels
it to do.

If I add an inform type method to the Prey class, the client must be
modified to call it or the Prey objects won't work right.

- - - - -
It is obvious (at least to me) why the "inform" interface is better, the
prey is making its own decisions as to what it will do in response to
the predators position (it may decide to charge rather than run for
example.) But the prey can't do the right thing, if it isn't informed
when the condition holds.

This also shows how DbC is an inherently procedural methodology. Well
constructed OO methods have no ensure clause.
.

Relevant Pages

  • 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: 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.
    ... 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: LSP and subtype
    ... whole tree_ to access it properly. ... If Sub1.foodoes so then the client will never notice a difference. ... client code will run just fine with *any* subclass object of Base, ... doesn't/shouldn't really tell its prey to respond to its attack. ...
    (comp.object)