Ok, this might not be possible, but I’ve got a class (called CompositeView) that’s a subclasses UIView. It uses some core graphics work to produce a custom background based on some options. Not a huge class, but bound to grow as my demands change/increase/whatever. The problem I’m having is I use this class a lot, in a lot of different places. But in a few of the places I need it to be a subclass of UIScrollView instead of a UIView. Interestingly enough, I can simply change the superclass and it all works perfectly fine. But not only do I not want all my other views to be a UIScrollView, it also interferes with the operation of some of them. So I need a class that’s sometimes a subclass of UIScrollView and sometimes a subclass of UIView.
For now, I’ve literally copied all of the interface/implementation of the CompositeView, changed the class name to CompositeScrollView, and changed it’s inheritance to UIScrollView. It works fine, but now I’ve got two sets of code that do exactly the same thing, just inherited from different parent classes. This makes keeping them both up to date a pain.
Is there a better way to do this?
Single inheritance languages force you to use delegation. You’d factor out the added functionality into a separate class that you instantiate for your derived classes and then write forwarding shims from the derived class to the instances. It’s painful.
Objective C has protocols which would describe the added functions (any shims that are not overrides) and then the compiler would error-out if you didn’t write the shim … which you still have to do manually.
Objective C also has categories that allow you to extend existing classes but these can’t be shared (you have to extend each class individually) so it doesn’t really help.