Re: Abstract classes and methods
Re: Abstract classes and methods
- Subject: Re: Abstract classes and methods
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 31 Aug 2001 00:40:02 -0400
>
From: stuartbryson <email@hidden>
>
>
In C++ it is possible to force both classes and methods to be abstract.
>
That is classes that cannot be instantiated without being subclassed and
>
particular methods overrided. How do I force abstract classes and
>
methods in Obj-C.
>
>
Thanks
>
>
Stuart
Oh, this thread gave me a headache. When I learned this kind of stuff in
Java it was so straightforward. We have abstract classes: they cannot be
subclassed. We have abstract methods: they must be overridden. We have final
classes and methods: they cannot be overridden. You cannot have a class
which is both abstract and final:
A compile-time error occurs if a class is declared both final and abstract,
because the implementation of such a class could never be completed
('8.1.1.1).
<excerpted from the Java language specification web pages>
Whether or not a non-instantiatable class is desirable I leave to those who
enjoy such arguments. Some of us will not desire to take advantage of
dynamism in all aspects of our programs, fools or no. But here is my idea
for designing a non-instantiable class in Obj-C.
You need two things: a core class, and a set of required methods. So, define
a class (myAbstractFamilyClass) and a protocol (myFamilyClassProtocol), as
in NSObject, but make your object a subclass of NSObject. Now either do 1 of
2 things: either have myAbstractFamilyClass adopt myFamilyClassProtocol and
provide some general or simplisitic implementation (just return some
uninteresting default value, say), or just have the instantiable subclasses
of myAbstractFamilyClass adopt myFamilyClassProtocol. The former approach is
used by NSObject:
The NSObject class is mostly an abstract class; programs use instances of
classes that inherit from NSObject, but rarely instances of NSObject itself.
<taken from the ref page for NSObject>
Note that the docs say "rarely" -- goes along with Ondra's point that, while
you may never need to do it, exactly what purpose is there to outlawing the
instantiation of a common base class? Well, we could always email Bill Joy
and ask why _he_ outlawed it... but I figure it is primarily a
conceptualization thing, and that for some people it is best to enforce a
distinction between essential features of a family of classes and the
specific features. Wait how about this: you get to specify instance
variables that you know you will need in the Class Family, you can write
implementations of methods that will be common and leave out those that
won't be... no I'm over-thinking, because in Obj-C myAbstractFamilyClass can
have implemented methods even if it doesn't adopt myFamilyClassProtocol
(strategy 2). myFamilySubClass will inherit all instance variables all
implemented methods, and still be required to implement protocol methods
too. Finally, non-instantiability can be almost recovered with strategy 2 if
the type of instance and return variables is declared using
myFamilyClassProtocol instead of myAbstractFamilyClass, so that you CANNOT
use myAbstractFamilyClass instances as place-holders, if that sort of
blocking behaviour is desperately desired.
So my answer to Stuart is that he use strategy 2 (declare a FamilyClass and
a FamilyProtocol, and then design FamilySpecificClass[ABCD..Z] which adopt
FamilyProtocol, and use FamilyProtocol to declare instances and return
types.
As a side note, in Java, Ondra's "place-holder" could be provided by
subclassing the abstract class and implementing any abstract methods with
dummy return values.
Brent