Re: Extending NSMutableDictionary what am I doing wrong?
Re: Extending NSMutableDictionary what am I doing wrong?
- Subject: Re: Extending NSMutableDictionary what am I doing wrong?
- From: Ben Dougall <email@hidden>
- Date: Fri, 27 Feb 2004 11:39:01 +0000
On Friday, February 27, 2004, at 12:03 am, Louis C. Sacha wrote:
Hello...
The reason that the initializers are raising exceptions is that the
default implementation of these intializers (in NSDictionary and
NSMutableDictionary) are written to do so. For most of the Apple
provided class clusters, when you make a subclass of the abstract
(public) class you are expected to completely override the "designated
initializer" with your own implementation (note: this is usually NOT
the case when you make a subclass of regular classes, this only
applies specifically to making subclasses in class clusters).
Even though it is possible to subclass NSDictionary, I'm not sure that
it would be the best solution. In general, you would only make a
subclass in a class cluster like NSDictionary if you wanted to change
the internal workings of the dictionary (for example if you wanted to
use a different algorithym to look up the objects from the keys, or
you wanted to change the way that the dictionary stores its objects
and keys).
If you want to make a class that uses a dictionary as storage, you
would instead "encapsulate" the dictionary in your class (if you look
at the class cluster documentation that Sherm linked to, this is what
it refered to as a "composite object")
http://developer.apple.com/documentation/Cocoa/Conceptual/Foundation/
Concepts/ClassClusters.html#//apple_ref/doc/uid/20000262/590141
There's an example in those docs that uses an NSMutableArray, but your
class would be similar but use an NSMutableDictionary instead.
-------------------- Page.h ------------------------
#import <Foundation/Foundation.h>
@interface Page : NSObject
but in that example NSArray (or NSMutableDictionary or whatever -- the
class cluster's abstract class) is actually subclassed. but because
subclassing a dictionary isn't a normal subclassing situation another
instance of a dictionary instance is still embedded within the new
subclass. all the required internal dictionary's methods are included
in the new subclass that just pass calls straight through to its
internal dictionary (if you don't want to modify them in anyway that
is), eg in the new subclass's .m:
- (id) objectAtIndex:(unsigned)index
{
return [embeddedDictionary objectAtIndex:index];
}
... etc for most/all dictionary's methods, plus the required new
extension methods obviously.
{
NSMutableDictionary *embeddedDictionary;
}
- (id)initWithTitle:(NSString*)title andText:(NSData*)text;
- (NSString*)title;
- (NSData*)text;
@end
----------------------------------------------------
-------------------- Page.m ------------------------
#import "Page.h"
@implementation Page
- (id)initWithTitle:(NSString*)title andText:(NSData*)text
{
if (self = [super init])
{
embeddedDictionary = [[NSMutableDictionary alloc]
initWithObjects:[NSArray arrayWithObjects:text, title, nil]
forKeys:[NSArray arrayWithObjects:@"text", @"title", nil]];
}
return self;
}
- (NSString*)title
{
return [embeddedDictionary objectForKey:@"title"];
}
- (NSData*)text
{
return [embeddedDictionary objectForKey:@"text"];
}
- (void)dealloc
{
[embeddedDictionary release];
[super dealloc];
}
@end
----------------------------------------------------
Hope that helps,
Louis
Thanks for the other question. I am right in thinking though I should
be able to subclass NSDictionary? If I do that and use exactly the
same code I get:
*** initialization method -initWithObjects:forKeys:count: cannot be
sent to an abstract object of class Page: Create a concrete instance!
Thanks,
Stefam
_______________________________________________
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.
_______________________________________________
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.