🚀 go-pugleaf

Bill Wolfe's most recent note about the need for specifications is
right to the point.  On the off chance that another explanation of the
same issue might help a few readers...

Suppose specifications describe only functional behavior, not
performance behavior, of components. Then it does seem natural and
valuable to factor out the commonalities among various implementations
and specify a single ABSTRACT component's functional behavior in a
single place (which many of us have called its specification).
Clearly, a reusable component might have multiple implementations in
this view of the world of "components."

Perhaps what's causing some confusion on this point is that everyone
doesn't seem to share this notion of what a reusable component is.  If
you think an IMPLEMENTATION is the focus of reuse -- the main thing
being reused -- then you might be tempted to think component
specifications should include performance information and that each
implementation should have separate specs (of both functionality and
performance behavior).  Bill and I and many others have been
proceeding on the assumption that the ABSTRACT functional behavior is
the focus, the abstraction the main artifact to be reused.  It serves
as the specification for many possible implementations precisely
because it doesn't tie down performance.

Implementations are also reused, but only by virtue of being correct
ways of achieving the required abstract functional behavior.  In fact,
they should be interchangeable in a client program from the standpoint
of correct functional behavior of the client.  Different
implementations will, of course, generally not have the same
performance for all the services provided by the abstract component,
and indeed should not, as Bill eloquently points out.

	-Bruce