Re: Creating a class cluster
Re: Creating a class cluster
- Subject: Re: Creating a class cluster
- From: Ondra Cada <email@hidden>
- Date: Sun, 28 Jul 2002 17:46:08 +0200
On Saturday, July 27, 2002, at 01:57 , David Newberry wrote:
I would like to create a class cluster. I have looked at the
documentation,
but I'm still confused. Since I'm creating the whole cluster (not basing
it off anything else), I create the "abstract superclass" as well as its
subclasses. It's creating the abstract superclass that's my problem right
now (I think). I've created a class to base the subclasses in the cluster
off, but I don't think it's "abstract." If it was abstract I assume that
I wouldn't have to have any code for it -- I'd assume that all it really
needs is a header file. But whatever I'm doing wrong, that's not the case
-- it complains if I don't provide the implementation.
Right, of course. Each class must have an implementation -- how otherwise
would the inheritance tree be realised?
The implementation, though, might be quite trivial -- a simple
@implementation Foobar @end
is sufficient: it makes the class object, which includes all the needed
pointers (like the one to its superclass) and other necessary information
and tables (like the class name, list of its methods, etc.).
The other thing I'm not sure about it creating instances of the class.
Consider my public class "DNClass" and its subclasses "DNSubClassOne" and
"DNSubClassTwo". If I wasn't using a class cluster, I'd use code
something like this to create new instances:
DNClass *var = [[DNClass alloc] initWithString:@"text"];
Well, primarily, you should not -- you should generally use either
[DNClass dnsWithString:...], or [[[DNClass alloc] initWithString:...]
autorelease], if the former is not available in API.
With a class cluster, though, initWithString: would be defined by one of
DNClass' subclasses. Since the subclasses will have different member
variables, it seems unlikely that I should be able to do this. Is it
correct that I'd have to embed a alloc...: method in each subclass, or is
the above code still legal with a class cluster?
Nope. You don't ever (well, for a relative newbie) implement your own
alloc. Here, you just exploit the fact (discussed in this list shortly ago)
that init can change the instance:
// your base class implementation
#import "HiddenSubclass1.h"
#import "HiddenSubclass2.h"
@implementation Foobar
-initWithString:(NSString*)s {
if (!(self=[super init])) return nil;
[self autorelease];
return [[[HiddenSubclass1 alloc] initWithString:s] autorelease];
}
-init {
if (!(self=[super init])) return nil;
[self autorelease];
return [[[HiddenSubclass2 alloc] init] autorelease];
}
...
Using bundle/category magic you can even make a "super-dynamic" init which
would without recompilation be able to return instances of classes unknown
now (made in frameworks/bundles in future), but I'd recommend to wait with
exploiting such tricks until you are more experienced with basics.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.