On Friday 18 October 2002 11:13 am, Massimiliano Mirra wrote:
> On Fri, Oct 18, 2002 at 12:16:30AM +0900, Paul Brannan wrote:
> > The argument I see over and over is that unit testing is an acceptable
> > and preferable alternative to contracts.  I'm not sure whether I agree.
>
> [Not strictly related to your post, Paul, just blatantly taking some
> words as an excuse to go off on a tangent.]
>
> When building contracts, interfaces and all that into a class, it
> seems to me that the programmer is trying to carry out two related,
> but different tasks: making the object behave in a certain way, and
> certifying that indeed it does.
>
> Now some things bug me about that.  First, as it has already been
> discussed in this group, even if a class implements, say, an interface
> that includes openFile(String path), inferring that upon calling a
> file will be opened is still a matter of deduction and trust.  The
> only thing we know for sure is that there is a method called
> `openFile' and that it accepts a String argument.
>
> Second, is certifying a behaviour really a class's responsibility?
>
<snip>
> Massimiliano

Thank you.  Finally, this discussion is getting down to it's philosophical 
essence.  An object's behaviour and the certification of that behaviour are 
two totally separate concerns.  Mixing the code from those two separate 
concerns just makes a muddy mess.  



-- 
Best essay I've read in years:
http://www.spack.org/words/commandline.html