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 <j...@mooseyard.com> wrote: > > On Dec 14, 2012, at 3:25 PM, Graham Cox <graham....@bigpond.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
