Re: Multiple inheritance and objective-c
Re: Multiple inheritance and objective-c
- Subject: Re: Multiple inheritance and objective-c
- From: Mark Dawson <email@hidden>
- Date: Mon, 21 Mar 2005 16:09:44 -0800
On Mar 21, 2005, at 3:51 PM, Mont Rothstein wrote:
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.
I own them, so I have the flexibility
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
Maybe I wasn't clear--class A's functionality has nothing to with C's.
The shared functionality has to with what B is adding to A (via the
subclass).
- 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.
I had thought about making C a subclass of B. It would carry all of
A's overhead, but that wouldn't harm anything functionality-wise. I
wasn't sure if that was good "OO" programing practice, though.
Hope this is at least a little help.
Thanks,
Mark
_______________________________________________
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