Re: OCUnit
Re: OCUnit
- Subject: Re: OCUnit
- From: Chris Hanson <email@hidden>
- Date: Fri, 22 Aug 2003 01:47:45 -0500
On Thursday, August 21, 2003, at 02:32 PM, Thomas Davie wrote:
Could you explain a little farther, my understanding was that if you
could instantiate a class then it wasn't an abstract class - As far as
I understood an abstract class contained an interface on which to base
a group of subclasses, but not the code to make the class it's self
useful.
When you say
NSMutableArray *array = [[[NSMutableArray alloc] initWithCapacity:0]
autorelease];
it may not actually be an instance of NSMutableArray that gets created,
but an instance of a specialized subclass.
In general, abstract classes aren't restricted to having no
implementation. Abstract just means a class shouldn't be instantiated
directly. In the case of NSMutableArray, it wouldn't necessarily be
correct to say it's an abstract class; rather, NSMutableArray is a
front-end to a class cluster and you need to obey the rules for
subclassing it detailed in the NSArray class cluster documentation if
you're going to.
From your other post, it looks like you're trying to create a
specialized subclass of NSMutableArray that only contains objects of a
specific type. Don't bother; this is almost never necessary in
Objective-C, and the compile-time type safety it buys you really isn't
worth much compared to having a comprehensive unit test suite or using
test-driven development.
Furthermore, in your case a TaskList has-a collection of Tasks, rather
than is-a collection of tasks. Just implement it to store its tasks in
a regular NSMutableArray, your life will be a lot easier.
Oh, and a cool trick is to implement the methods expected by the
NSScriptKeyValueCoding protocol (i.e. -insertIn<property>:atIndex:
etc.) and use them to manipulate to-many relationships like the Tasks
in a TaskList; this makes it even easier to add AppleScript support to
your application, without much up-front cost beyond a standard
method-naming convention for relationship accessors.
(One thing missing from NSScriptKeyValueCoding is a
-removeValue:fromPropertyWithKey: message that maps to
-removeFrom<property>:. This is necessary for symmetry with
-insertValue:inPropertyWithKey: and is useful in situations where the
to-many relationship isn't really ordered.)
-- Chris
--
Chris Hanson, bDistributed.com, Inc. | Email: email@hidden
Custom Mac OS X Development | Phone: +1-847-372-3955
http://bdistributed.com/ | Fax: +1-847-589-3738
http://bdistributed.com/Articles/ | Personal Email: email@hidden
_______________________________________________
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.
| References: | |
| | >Re: OCUnit (From: Thomas Davie <email@hidden>) |