Introduction object-oriented programming

[Peter Hansen]

Mike Meyer wrote:
> 
> "Donnal Walter" <donnalcwalter at yahoo.com> writes:
> 
> > [OT] One of Eiffel's strengths is design by contract (DBC). I've considered
> > implementing one of the published recipes for EiffelMethods in Python, but I
> > wonder, is DBC is really necessary if one uses unit tests compulsively?
> 
> I don't know about "necessary", but there are uses for DbC that unit
> testing can't cover, and uses for unit testing that DbC can't cover.
> See <URL:
> http://scom.hud.ac.uk/staff/scomdjd/public/XP/UT/dbc-and-unittests.html
> > for an extended discourse on these topics.

As someone unfamiliar with DbC, I'm uncertain whether my initial
reaction to reading that page is fair or whether the page itself 
has perhaps somewhat poor coverage of DbC.

Does this page really reflect the essence of DbC and the way in 
which it is applied?  If it is, I would have to conclude that not
only do I see little value in it, but that with proper unit and
acceptance testing I see *no* value in DbC, and perhaps even some
negative aspects.

One small example of an area that bothers me -- not even related to 
unit testing -- is the comparison under the subtitle "But isn't 
defensive programming good thing?" (sic).  It shows the DbC approach 
as doing exactly what we often recommend *not* doing in this 
newsgroup: attempting to verify a condition exists prior to actually
performing the operation that requires that condition.  The
so-called "defensive" programming version (I would have used that
term for the DbC version, but maybe "defensive" has a reserved
meaning in DbC for all I know) shows the more Pythonic approach of
just performing the operation, then catching the exception if
one occurs.

Independent comments on that page and this issue in general would 
be welcome.

Comments which manage to tie it back to Python would be even more
welcome. :-)

-Peter