"Nat Pryce" <nat.pryce / b13media.com> schrieb im Newsbeitrag
news:1035212081.3359.22.camel / ballsup...
> On Sun, 2002-10-20 at 04:12, Jim Weirich wrote:
> > On Fri, 2002-10-18 at 14:08, Nat Pryce wrote:
> >
> > > [...] Also, in my experience, DbC ends up polluting the class
> > > interface with a lot of predicates, because it doesn't support the
idea
> > > of protocols, [...]
> >
> > I'm not sure I understand the above comment.

i think i understand the comment but i am not sure whether i can agree the
implications:

> Often, when designing classes you define a protocol by which calls can
> be made to the object.  A simple example, a Socket object has methods to
> connect, read and write data, shutdown the read or write stream, or
> close both streams.  You must call connect before calling read, write,
> shutdown or close.  Once you've called close, you cannot call read or
> write again until you call connect again.  Once you've shutdown the read
> stream you cannot read, and similarly for write shutdown.

yepp.

> Client code that uses a socket keeps track of the socket state by its
> own control flow.  A socket can only be in a closed state if it has been
> closed by the client code (ignoring errors in this example).

that's true.

> However, to specify this protocol in DbC you have to define
> preconditions on whether the socket is open, and those preconditions
> have to be defined in terms of public methods.  E.g. the read method
> might be:
[snip]
> So you end up adding predicates to the public API of objects to track
> the progress of the protocols used to interact with those object.

is this really that bad?  i mean, the pre- and postconditions are a way of
representing the protocol.  you could argue that it is not as readable as an
uml sequence diagram.  however, my impression is that the protocol is a by
product of a class's semantics, which are reflected in the contract.

>  Often
> this also requires adding data members to keep track of the current
> state of the object.

is this really the case? i mean, taking your socket example your class will
have to store a file descriptor anywhere or something equivalent.  if that
descriptor is ni, NULL, -1 or whatever other special value this corresponds
to being closed.  the read method has to be able to determine whether the
stream is open anyway.  so, to me it seems there is no additional state
necessary.

more abstract: if there is no state already present in a class representing
some protocol state, of which use would a protocol condition be then?  if,
from the semantics of the class at hand, there is no distinction which sense
does a special protocol state make?  (i'm awfully struggling to find the
right words, so please bear with me.)

<soapbox>i conclude, it is never necessary to add state to support the
protocol.</soapbox>

> I found that when writing code that had a lot of composition, rather
> than inheritance, contracts of classes would end up mirrored in the
> interface of other classes that contained them, and in containers of
> containers, and so on.  If you changed the contract of a component
> class, then the change would ripple through the containers.  In very
> compositional code, it became quite expensive to change contracts.

the same story for adding / removing method arguments and exceptions.

regards

    robert