Re: Multiple inheritance and objective-c
Re: Multiple inheritance and objective-c
- Subject: Re: Multiple inheritance and objective-c
- From: Mont Rothstein <email@hidden>
- Date: Mon, 21 Mar 2005 15:51:45 -0800
A big question here is how much flexibility you have. If you can't change B because you don't own it, or others already use and depend on it, then your options are different than if you can change it.
If you own B and can do what you want with it, and assuming that B and C have 10% different from each other. Then a few of options I see are:
- Add the 90% to A and subclass both B and C from A
- Create a new subclass of A called D with the shared 90% and subclass B and C from it.
- A non-obvious one to C++/Java programmers is simply add C's differences to B. One of the things that Apple's frameworks due well is to not over fragment. This isn't a call that can be made without knowing more, but it isn't necessarily wrong to have a large B rather than slightly smaller B and C separately (ex: NSWindow is *huge* and it is a good thing). Generally Obj-C classes (by convention) tend to be larger than C++ or Java classes.
If you don't own B then your options are more restricted, and can get uglier.
- Subclass C from B ignoring what C doesn't use out of B
- Slap a category on B (or even A) that forwards C's additional 10% to C
- Use poseAsClass: to replace B with MyBC which has your additional instance variables
- Use a class variable to sneak in some added instance variables
There isn't a single answer, it very much depends on the situation. If you have the option, code re-organization is usually the best. C++ class hierarchies do not usually look much like Obj-C ones for equivalent functionality.
Hope this is at least a little help.
-Mont
On Mar 21, 2005, at 3:32 PM, Mark Dawson wrote:
That would improve the issue, but that would still mean that I'd have to implement all of the method, even if that just meant passing them through, right? I have 20-30 methods that are in common.
So class C would have
@@interface class C {
NSMutableArray * mArray;
}
-getXXX1; ... -getXXX10;
-setXXX1(int) x; ... -setXXX10(int) x;
@end
Class B would look something like (assuming I could inline like C++):
@interface class B : class A {
C *mSharedClass;
};
-getXXx1() { return [mSharedClass getXXX1]; }
..
-getXXx01() { return [mSharedClass getXXX10]; }
@end
On Mar 21, 2005, at 3:15 PM, John C. Warner wrote:
On 21 Mar, 2005, at 6:11 PM, Mark Dawson wrote:
I have class B that inherits from class A. I now need to make a class C. It turns out that 90% of the functionality (including class variables) would be shared between B's implementation (its subclass implementation) and C's implementation. In C++, I would break out that functionality, creating class D. Class B would inherit from A AND D, while C would inherit from D. I know that objective-c doesn't have multiple inheritance, so I was wondering how similar class functionality is handled there. Note that I DO have class variables (instance variables), which precludes using categories to support this.
Can you just make Class C keep an instance of Class B as an instance variable?
-John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden