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: Jens Alfke <email@hidden>
- Date: Sat, 15 Dec 2012 13:28:54 -0800
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