Re: Q's about Obj-C
Re: Q's about Obj-C
- Subject: Re: Q's about Obj-C
- From: Ondra Cada <email@hidden>
- Date: Tue, 16 Oct 2001 12:02:05 +0100
Normand,
>
>>>>> Normand Rivard (NR) wrote at Tue, 16 Oct 2001 00:22:48 -0400:
NR> I have to disagree on this, Ondra. Java is a dynamic language too and it
NR> is possible (and sometimes desirable) to declare a class as abstract. Try
Java is not dynamic enough. With regard of this debate, the most important
drawback is that it uses C++-like constructors. Since that, it can't properly
support class clusters.
NR> to dynamically instanciate an abstract class like in the example and you
NR> will end up with an exception.
Of course ObjC can do _runtime_ checking too, as I've written in original
message; which is impossible in ObjC (nor in Java if you use reflect) is
compile-time C++-like approach. So, should you want to (and again: *NEVER* in
decades of OO programming I've encountered such a need):
-init {
[self autorelease];
[NSException raise:@"Abstract!" format:@"Attempt to create an instance of
anstract class %@",[self class]];
return nil; // just to suppress the warning
}
NR> The concept of abstract class has _nothing_ to do with memory allocation.
That's true, and so what? Never I (not anybody other so far as I know) said
that it has.
NR> It has to do with data modelling and code maintenance. It is a software
NR> engineering issue, not a memory management issue. When I declare a class
NR> as abstract, I am really saying to the compiler : "make sure no one ever
NR> try to instanciate this class, because I (as a class designer) have
NR> decided that it doesn't make sense."
The problem with this approach is that in 100 cases of doing that it might
be once a reasonable thing, but 99 times it is a grave design error.
Take NSObject: should it be noninstantiable, it couldn't be used as a
placeholder -- which is often a quite desirable thing.
NR> Too bad the only way to protect my design in Obj-C is to write a
NR> comment...
Too bad you don't understand the following code -- both variants are
*considerably* stronger than "just a comment":
NR> (ii) You can have runtime-abstract class if you really want to (though I
NR> haven't *EVER* seen a situation when this would be desirable!!!):
NR>
NR> @implementation AbstractClass
NR> -init {
NR> [self autorelease];
NR> NSLog(@"Attempt to create an instance of anstract class %@",[self
NR> class]); return nil;
NR> }
NR> ....
NR> @end
NR>
NR> (iii) Instead of the slightly pathological situation of (ii), you can --
NR> thanks to the fexibility of the alloc/init system -- implement class
NR> clusters instead:
NR>
NR> @implementation AbstractClass
NR> -init {
NR> [self autorelease];
NR> return [[SomeReasonableConcreteSubclass alloc] init];
NR> }
NR> ....
NR> @end
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc