Re: Correct way to make mutable and immutable objects?
Re: Correct way to make mutable and immutable objects?
- Subject: Re: Correct way to make mutable and immutable objects?
- From: Graham Cox <email@hidden>
- Date: Mon, 17 Dec 2012 21:18:09 +1100
Thanks for your insights guys...
I think the separate header for the mutating methods in a category should be enough in this case.
--Graham
On 16/12/2012, at 8:28 AM, Jens Alfke <email@hidden> wrote:
>
> On Dec 14, 2012, at 3:25 PM, Graham Cox <email@hidden> wrote:
>
>> I have an abstract base class A and a mutable subclass AM. The class A owns a list of subsidiary objects but only the class AM has the methods for adding and removing these , which is what 'mutable' means for this class.
>>
>> There are a series of concrete subclasses B, C, D, etc which all set up the subsidiary objects in various configurations when they are initialized, but once done, the clients of these objects have no business mutating them so they need to be returned as the immutable variant.
>
> This is a classic OOP design problem — it’s one of the things multiple inheritance or mixins are supposed to solve. You’d make the mutability API a mixin class that could be inherited by mutable subclasses of A, B, C, etc — AM, BM, CM. There’s no way to do this in Obj-C, though — and in practice this capability tends to introduce all kinds of complications in languages that support it like C++.
>
>> However, in order to work during setup they are in fact subclasses of AM.
>
> That’s one way to do it in Obj-C. Another way is to get rid of the distinction between A and AM and just make mutability a boolean attribute of an instance. The mutating methods can have assertions that check this. This is the way that the collection classes in Foundation/CF work.
>
>> Is there a way to return them as if they were subclasses of A, so that the existence of the mutating methods is hidden from the client code?
>> It only needs to go as far as flagging a compile warning if the client attempts to use a mutating method
>
> I’d put the mutating methods in a category in a separate header file. That way the code that needs to use them can #import that header and use the API, but it’s not generally known to clients.
>
> —Jens
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden