Abstract class

[Stephen Horne]

On 14 Sep 2008 20:25:18 GMT, Steven D'Aprano
<steve at REMOVE-THIS-cybersource.com.au> wrote:

>"The fact that many languages disallow instantiation of abstract types 
>(and force subtypes to implement all needed functionality) further 
>ensures program correctness."
>
>http://en.wikipedia.org/wiki/Abstract_base_class
>
>but I don't see how that follows (except possibly in very special cases). 
>Given that the set of instances of class B is empty, how does that help 
>you know that B.method is correct?

That's the point - to be certain that the set of instances of class B
really is empty.

As for B.method, it's correctness isn't purely determined by the code
of the method itself. It will usually depend on the object being in a
self-consistent state. It's often impossible for an instance of an
abstract base to have a self-consistent state. Therefore, it's better
to guarantee that no instances can be accidentally created.

OTOH, this argument is often an over-pedantic technicality. You can't
eliminate all errors from code by making the language stricter.
Instantiating an abstract class isn't a very common error in my
experience. Whether detecting it is a priority depends on what you're
doing.