What to include in Foundation-like subclasses
What to include in Foundation-like subclasses
- Subject: What to include in Foundation-like subclasses
- From: Bill Cheeseman <email@hidden>
- Date: Sat, 14 Jun 2003 06:58:41 -0400
I haven't seen a checklist of what methods to include in a basic,
Foundation-like subclass of NSObject. Any advice?
Suppose I'm writing a subclass of NSObject for public distribution that
implements some general Foundation-like capability, such as a new data type.
Here's my current working list:
1. A designated initializer
2. Secondary "designated" initialiers for various incoming data conversions
to my new type, such as -(id)initWithString:(NSString *)string and
-(id)initWithData:(NSData *)data, if appropriate.
2. Class methods that allocate and initialize a new object of my new type,
to cover both kinds of initializers, and return it autoreleased, as a
convenience.
3. -(void)dealloc, assuming my class has one or more instance variables that
need deallocating.
4. Methods that return converted values, the mirror image of item 2, above.
For example: -stringValue and -dataValue.
5. Comparison methods, including -isEqualToMytype:(Mytype *)aMytype and
-compare:(Mytype *)aMytype. This would include special methods to identify
particular kinds of Mytype objects, if appropriate, such as
-isNilMytype:(Mytype*)aMytype.
6. If MyType is covering some industry-standard data type that specifies
versions or the like, special methods to return the specified versioning
info. For example: -(unsigned int)version:(MyType *)aMytype.
7. -(NSString *)description, for debugging, etc.
8. If Mytype is a wrapper for a Core Foundation or other opague data type,
which is held in my class in an instance variable, a method to get it back
out for the benefit of people who want to intermix my Objective-C class and
pure Carbon calls. For example, -(CFMytypeRef)mytypeRef. The Core Foundation
object would be returned CFRetained and should be documented as such.
9. -copyWithZone:(NSZone *)zone, to comply with the NSCopying protocol. And
-mutableCopyWithZone:(NSZone *)zone, to comply with the NSMutableCopying
protocol, but only if Mytype has a mutable counterpart.
10. -initWithCoder:(NSCoder *)decoder and -encodeWithCoder:(NSCoder
*)encoder, to comply with the NSCoding protocol. These should branch on
([coder allowsKeyedCoding]) and provide code for both old-style sequential
archiving and new-style keyed archiving.
What have I left out? Are any of these wrong or inappropriate?
I wonder, for example, about Foundation's NSKeyValueCoding informal
protocol. Is there anything in this I would normally have to implement, or
only in special situations? The documentation leaves me a little confused,
but it seems to say that in the ordinary case I can rely on NSObject's
implementation of these methods.
And what about the AppleScript-related Foundation informal protocols? I
haven't explored this yet, but it seems as if I can typically rely on
NSObject's implementation for these, too.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
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.