Correct way to make mutable and immutable objects?
Correct way to make mutable and immutable objects?
- Subject: Correct way to make mutable and immutable objects?
- From: Graham Cox <email@hidden>
- Date: Sat, 15 Dec 2012 10:25:57 +1100
Hi all,
I'm having trouble getting this to work how I think it should, i must be missing something.
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. However, in order to work during setup they are in fact subclasses of AM. 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, it doesn't need to go as far as return NO from -respondsToSelector: for these methods, since in reality they are in fact AM subclasses. Is it just a case of putting these methods into a category that is included by B, C, D but not by client code, so that such methods don't exist in the public interface? What's the usual solution?
--Graham
_______________________________________________
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