[3386] in java-interest
re:abstract methods
daemon@ATHENA.MIT.EDU (Gary Aitken)
Thu Nov 9 23:34:36 1995
Date: Thu, 9 Nov 1995 18:29:35 -0700
From: garya@village.org (Gary Aitken)
To: "andrew (a.) francis" <andrewfr@bnr.ca>, garya@village.org
Cc: "fergal (f.k.) connellan" <connef@bnr.ca>, java-interest@java.sun.com
In-Reply-To: <"23290 Thu Nov 9 18:54:01 1995"@bnr.ca>
>G> Yes, but you lose the reason the abstract method exists -- forcing the
>G> derived class to override the method. The whole purpose of the abstract
>G> method is to force the implementor of a derived class to implement the
>G> method. If you don't make it abstract, one can derive and forget to
>G> do the override, causing incorrect behavior.
>
>Not really, a major purpose of abstract classes is to impose a particular
>interface upon sub-classes, rather then imposing a particular behavior
>(the method body provides the behavior).
I disagree. The class definition as a whole imposes the interface upon
the subclasses; whether a class is abstract or not only effects which
portions of the implementation the subclass is required to implement.
You can't impose behavior, obviously.
If you can't impose the part of the interface which is required to
be implemented, you risk getting improper behavior.
If you have a design in which a base class implements behavior which
must be extended by a subclass by appending or prepending to the
base class behavior, and you do not allow an abstract class to have an
implementation in the base class, there is no way to impose the part of
the interface which must be extended on the subclass.
i.e. as soon as you provide the base class portion of the implemention,
you forfeit the ability to require the subclass to do its mandatory
extension to the semantics.
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
