Re: Class Clusters
Re: Class Clusters
- Subject: Re: Class Clusters
- From: John Anderson <email@hidden>
- Date: Wed, 21 May 2003 19:30:31 -0400
On Tuesday, May 20, 2003, at 12:14 America/Detroit, Drew McCormack
wrote:
Hi John,
Thanks for your reply.
I strongly recommend that you study the ClassCluster tutorial written
by "KritTer" (Chris Purcell) at CocoaDev:
http://www.cocoadev.com/index.pl?ClassClusters
Basically, the "better way" of dealing with your problem of creating
an infiinite loop and such is by implementing a private "placeholder"
class that handles the initialization and allocation of your concrete
classes of your cluset like so:
I actually did read this article. I don't really understand what the
purpose of the placeholder class is. The article just says we do it
"...because Apple does it...". I can't see the difference between
returning a DataSet instance or a PlaceholderDataSet instance from
DataSet's alloc method.
Frankly, I think that the idea of class clusters is largely an
aesthetic concept anyways. So the difference between using a
"placeholder" class or not, may be viewed in in terms of what
constitutes "good" ObjC coding practice rather than actually providing
additional functionality. Here we are talking about clearly separating
the special allocation and complex initialization methods that are the
private core of the class cluster paradigm from the public interface
class. On the other hand, as class clusters become more complex the
functional utility of the "placeholder" class may become apparent for
reasons that are not clear to us at this time.
And as far as I can tell, it doesn't actually help with my problem. My
question is, in the init... methods of the private subclasses of
DataSet, which DataSet constructor should I chain to? In the example
you have given, the problem still exists, because your DataSet "init"
method returns nil. So you can't do this in FileHandleDataSet, for
example,
-(id)initWithFileHandle:(NSFileHandle *)fh {
if ( self = [super init] ) {
....
}
return self
}
because [super init] is the DataSet init method, which returns nil. I
guess the init method of DataSet should be omitted, and then everything
will work, right?
Drew
Yes, you are absolutely correct. In my haste, I forgot that [DataSet
init] should return an actually object based on [super init], or not be
overridden at all.
DataSet
+ (id)alloc
{
if ([self isEqual:[MyMatrix class]])
return [MyPlaceholderMatrix alloc];
else
return [super alloc];
}
-init {returns nil }
-initWithData {returns nil }
-initWithFileHandle {returns nil }
PlaceholderDataSet
-init {returns [[InMemoryDataSet alloc] init ...}
-initWithData {returns [[InMemoryDataSet alloc] init ...}
-initWithFileHandle {returns [[FileHandleDataSet alloc] init ...}
Truly yours,
John Anderson
On Tuesday, May 20, 2003, at 06:56 America/Detroit, Drew McCormack
wrote:
I am trying to write a simple class cluster, but have come up against
a problem. My basic design is this:
DataSet
-init (returns a InMemoryDataSet)
-initWithData (returns InMemoryDataSet)
-initWithFileHandle (returns FileHandleDataSet)
FileHandleDataSet : DataSet
-initWithFileHandle
InMemoryDataSet : DataSet
-initWithData
DataSet is the public abstract base class to the other two.
If the initWithData method of DataSet gets called, it tries to create
an InMemoryDataSet object and return that in its place. To do this it
calls the "initWithData" method of InMemoryDataSet. But the
initWithData method of InMemoryDataSet needs to initialize its
superclass by calling init, ie,
-(id)initWithData:(NSData *)data {
self = [super init];
return self;
}
This calls the init method of DataSet, which is also designed to
create and return a InMemoryDataSet, creating an infinite loop.
How should this be avoided? Should I just check the class of the
sender in the init method of DataSet to determine my course of
action, or is there a better way?
ie.
-(id)init {
if ( [[self class] isEqual:[DataSet class]] ) {
[self release];
self = [[InMemoryDataSet alloc] initWithData:nil];
}
else {
self = [super init];
}
return self;
}
Drew
========================================
Dr. Drew McCormack (Kmr. R153)
Afd. Theoretische Chemie
Faculteit Exacte Wetenschappen
Vrije Universiteit Amsterdam
De Boelelaan 1083
1081 HV Amsterdam
The Netherlands
Email email@hidden
Telephone +31 20 44 47623
Mobile +31 6 483 21307
Fax +31 20 44 47629
_______________________________________________
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.
----------------------------------
Dr. Drew McCormack
Trade Strategist (www.trade-strategist.com)
Stock Market strategy design platform for Mac OS X.
_______________________________________________
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.
_______________________________________________
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.