Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <54917@microsoft.UUCP>
Date: 29 May 90 19:01:08 GMT
Article-I.D.: microsof.54917
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 37

In article <5121@stpstn.UUCP| cox@stpstn.UUCP (Brad Cox) writes:
|The chicken
|is the object-oriented tools, where by 'object-oriented', I'm referring to
|open universe languages (Smalltalk, ObjectiveC) that do not insist that the
|relationship between parts and the whole be known and declared in advance,
|at compile-time, as the universe is being created by the compiler. In
|closed-universe languages (Ada, C++, Object-Pascal, etc), i.e. strongly
|type-checked languages, all such relationships must be known and declared
|at compile time.
|
|Open universe languages simply provide support for solving open-universe
|*problems* (collections of unknown components, pluggable software components,
|software components marketplaces, etc).
|
|But open universe problems are intrinsically more difficult to test than
|closed universe problems, independently of the tools used to build them.
|
|In other words, the testing difficulties arise from the nature of the problem,
|not from the nature of the object-oriented tools used to solve them.

Well, clearly I disagree with both Brad's notion of "object-oriented" and
"Open-Closed."

Ideally, since in real-world libraries over half the classes are leaf classes,
I'd like to be able to specify a leaf class as being such, and declare it
"Closed."  A class declared closed can no longer have its methods overridden,
changing their meanings of its methods.  This would allow a compiler to 
significantly optimize the closed class, and would allow testing the closed
class as a module with fixed meaning.  An object of a closed class could 
still be embedded [has-a], or inherited from for purposes of pure,
orthogonal, extension -- you can add methods, but not change existing
methods.

Classes defined as being inheritable, and whose methods can be overridden
would be considered "Open."  I don't know how you really test these, but
they still would be useful components for making closed modules.  And at
least closed modules can be reasonably tested.