Re: Abstract classes and methods
Re: Abstract classes and methods
- Subject: Re: Abstract classes and methods
- From: Chris Gehlker <email@hidden>
- Date: Wed, 29 Aug 2001 00:23:06 -0700
On 8/28/01 10:39 PM, "Greg Titus" <email@hidden> wrote:
>
Well you _can_ define a base class that inherits from nothing, of
>
course - it's just pretty rare.
Yes you can. It's just so unusual, and hard to do right, that I was ignoring
it.
>
And even a class which is farther down
>
in the inheritance tree could still be abstract - it isn't that uncommon
>
to have an abstract subclass of a concrete base class.
We have fallen into a language morass. It's partly my fault because Stewart
said "abstract" when he meant "virtual" and I let it slide. So it might be
helpful to review the definitions.
Virtual - Can't be instantiated which is enforced by the language.
Abstract - Might be a good candidate for sub classing. May or may not be
virtual. Indicated by declaring the destructor virtual.
Concrete - Not intended to be sub classed. Indicated by not declaring the
destructor virtual.
Now given this common C++ usage, it should be very rare to subclass a
concrete class. The author is telling you it isn't a good idea. It's also
dangerous in C++ because the destructor may not be polymorphic.
Now as far as I can tell, ObjC doesn't have these conventions for indicating
how you intend a class to be used. Every class is non-virtual and abstract.
>
But, any time
>
when you are thinking in terms of an abstract super class in
>
Objective-C, you should probably consider whether a protocol would be a
>
better idea.
This just really looses me. Lets look at a classic abstract class like
"shape" in a drawing program. You can define a lot of methods for shape
like move, erase, and rotate. But you can't define them all. Stroke or fill
can only be defined for particular shapes like circles and rectangles. So
you write your program in terms of messages to shape but design your palette
so the user can only choose concrete instances. Then when the user clicks on
a pentagon and chooses fill you send [shape fill] and everything works
because the message will always go to a concrete class that know how to fill
itself.
I'm just not seeing how protocols come into this scenario. Protocols are for
things that are orthogonal to the class hierarchy according to Apples
ObjC.pdf book. I would use protocols for things like copying and
persistence. Am I all wet here?
--
Many individuals have, like uncut diamonds, shining qualities beneath a
rough exterior. - Juvenal, poet (c. 60-140)