[3244] in java-interest
Re: abstract methods
daemon@ATHENA.MIT.EDU (Gary Aitken)
Sat Nov 4 14:13:19 1995
Date: Sat, 4 Nov 1995 10:25:10 -0700
From: garya@village.org (Gary Aitken)
To: jeremy@suede.sw.oz.au (Jeremy Fitzhardinge)
Cc: java-interest@java.sun.com
In-Reply-To: <9511041332.AA03064@suede.sw.oz.au>
>> The java spec section 4.10.5 says that abstract methods cannot contain
>> a body. Why is this restriction made?
>
>You seem to have virtual and abstract methods confused.
Nope.
> The whole
>point of an abstract method is that it defines an interface which
>a derived class must implement, but is itself in a non-instantiatable
>class.
Correct. The *class* is non-instantiatable. That does not imply that
an abstract method has no body.
>If you want to have a method with a default action which can
>be overridden, then you just need a normal (non-abstract, non-final)
>method. Unlike C++, all methods are "virtual" by default.
Also true. That is all you *need*. However, the purpose of an abstract
method is to force implementation overriding the method in any derived class.
There are some categories of functions, such as the examples I provided,
where a function requires a body to be implemented in the base class,
and which by design also require refinement in any derived subclass.
toString is a prime example; the documentation even states that all
derived classes *should* override it. It's not a requirement per se.
But if the derived class is to play well in the entire environment, that
method will need to be overridden. If you look at any large development
project, a project manager / technical lead will want these to be abstract
methods, to force them to be overridden, to insure the classes play well
in the total environment. Saves *buckets* of debug time and support
questions.
Gary Aitken garya@village.org
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
