• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: "Subclass" NSMutableArray basic concept?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Subclass" NSMutableArray basic concept?


  • Subject: Re: "Subclass" NSMutableArray basic concept?
  • From: daniel <email@hidden>
  • Date: Mon, 7 Feb 2005 13:30:25 -0800

Just to clarify what it is you're doing - it's not so much subclassing as composing and encapsulating. Your DBPersonList class acts like an array but is not one. It contains one, and uses it to provide service to its clients without exposing the fact that it's really just an NSArray. I think this is a reasonable approach to implementing array-like access without depending on NSArray as the long-term implementation method.

If you're going to allow the client to access the underlying NSArray, then the encapsulation is broken. Since you've exposed the array, you will for all time need to either implement the class as an NSArray wrapper, or produce a compatibility NSArray for clients who need it. You might look at your code that "needs" the array and ask whether another level of abstraction would help eliminate the need. For instance, if you implement methods "personAtIndex" and "personEnumerator", do you still need direct access to the NSArray? It's probably easier to meet the contractual agreement of providing your clients an "NSEnumerator" forever. For instance, if you changed your implementation to using NSDictionary instead of NSArray, you could simply change the method that returns the enumerator to return the dictionary's value enumerator.

Of course, if your "DBPersonList" class doesn't really add any value to the NSArray that it wraps, and you don't see DBPersonList changing dramatically in the future, then you might ask yourself whether there's any point in having the class at all. If DBPersonList doesn't have additional data members besides the NSArray, then you could probably do this more simply with a category. In that scenario, you would define methods like "addPerson" in a category of NSArray, which would allow you to do something like this:

NSArray* myPeople = [NSArray arrayWithCapacity:0];

[myPeople addPerson:[DBPerson defaultPerson]];

And you could still add whatever extra custom code you desired to the addPerson method.

Daniel

On Feb 7, 2005, at 1:00 PM, dkb wrote:

I am wondering if my approach to "subclassing" NSMutableArray's is correct.

If I have a list of people modeled by DBPersonList class (which contains a list of DBPerson objects) and I have a method called "list" which returns the NSMutableArray containing the DBPerson objects. I also have convenience methods such as "-addPerson".. so I can do [personList addPerson:newPerson] instead of [[personList list] addObject:newPerson]. When I need to use the actual array though I do use [personList list].

Is this the best approach?  Thanks..

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >"Subclass" NSMutableArray basic concept? (From: dkb <email@hidden>)

  • Prev by Date: Using NSDictionary to write to /Library/Prefererences
  • Next by Date: Re: Binding and NSPopUpButton selectItemAtIndex
  • Previous by thread: "Subclass" NSMutableArray basic concept?
  • Next by thread: Using NSDictionary to write to /Library/Prefererences
  • Index(es):
    • Date
    • Thread