Returning mutable vs. returning immutable (non-member-)objects

I hardly ever see the second one used and I wonder why?

• Neither would it break support for situations where an NSArray is expected (as it's a subclass).
• Nor would it break encapsulation by revealing mutable internals.

Under the precondition that it's never a mutable ivar that's returned, ^{(which should be common sense anyway)}

I can right now only think of advantages of using the second.

• It actually is mutable. And muting is safe here, so why prevent it?
• No need to call [[[foo fooBar] mutableCopy] autorelease], which needlessly allocates additional memory and needlessly wastes time.

Here are the method variations:

- (NSArray *)fooBar {
    NSMutableArray *fooArray = [NS开发者_C百科MutableArray array];
    //populate fooArray
    return fooArray;
}

- (NSMutableArray *)fooBar {
    NSMutableArray *fooArray = [NSMutableArray array];
    //populate fooArray
    return fooArray;
}

I'm asking as my project has a bunch of methods with the same pattern.

And in most of the times the returned array will be modified afterwards (merged, edited, etc).

So I think it should be totally fine to return NSMutableArrays, yet nobody seems to be doing it.

NSMutableArray, NSMutableSet, NSMutableDictionary… it's basically the same deal.

---

For an explanation of using mutable versus immutable, check out Apple's documentation on Object Mutability.

In general, it is best to return an immutable version, unless it is specifically your intent that the object returned always be an immutable object available for any client to change. You should create your interfaces based on the intent of the interface, not off the current implementation. It is possible that requirements will change and you will need to change the implementation of fooBar such that it does return an instance variable. By returning mutable arrays you ensure that you encapsulate not only your instance variables, but your current implementation.

So, you may have a valid place to return a mutable array (I don't know), but you see most code passing immutable arrays because it fully encapsulates their variables and their implementations.

---

I suppose the first variation was preferred because polymorphism was preferred.

In either case, both methods return an instance of NSMutableArray, the only difference being that the first one hides that fact from the caller. In other words, the first variation is not safer than the second. It's essentially using polymorphism to tell the caller that any type of NSArray might be returned. If you need that kind of flexibility in your code, it definitely has it's advantages. (e.g., if one day, for whatever reason, you need to return a custom NSArray subclass, your code won't break at that level).

However, you seem to prefer communicating intent to the caller - i.e. that you actually return mutable arrays - which is also OK. To make everyone happy (if there is such thing anyways...), I suggest renaming the 2nd method to:

- (NSMutableArray *)mutableFooBar {
    NSMutableArray *fooArray = [NSMutableArray array];
    //populate fooArray
    return fooArray;
}

As a side note, I think that the following is a slightly more efficient way to convert an existing immutable array into a mutable one:

NSMutableArray *mutableArray = [NSMutableArray arrayWithArray:fooArray];

(correct me if I'm wrong on that assumption).

I hope this answers your question...

---

Having a method return a mutable instance like that looks suspicious.

As the caller you have to question the original method signature and wonder if it really is safe to mutate the returned value. After all the class may inadvertently be returning a pointer to internal state.

If profiling reveals that this copy is indeed expensive, I usually change the method signature to make it obvious that the mutability is intended. Perhaps with something like:

- (void)populateFooBars:(NSMutableArray *)array;

That way it is clear that the mutability of the result is intentional.