Re: Question
Re: Question
- Subject: Re: Question
- From: "Eduardo I. Jiménez" <email@hidden>
- Date: Mon, 3 Dec 2001 22:23:59 -0500
On Monday, December 3, 2001, at 08:18 AM, Ondra Cada wrote:
Eduardo,
That almost surely means that your design is flawed (making a number of
unnecessary classes). So many classes there roughly is in both
Foundation +
AppKit; I don't think the complexity of your application is in the
order of
complexity of the whole Cocoa!
First of all, it is not my design. Second, Foundation and AppKit
implement massive functionality on large objects.
EIJ> Now, my basic problem is the following: this design has
EIJ> many classes with multiple inheritance
A multiple inheritance is a design flaw almost each time it is used. Of
course there are exceptions, and your classes might be those... but
it's not
probable.
Well, how would you know that?. I don't want to disagree but I think you
should ask first why exactly I need MI. The design I have makes the
right use of MI, and I can't share any more of the details, but let's
say a committee of people (VERY qualified people from an academically
famous organization) came up with it and I've personally investigated on
the matter.
EIJ> Also, does anyone have an useful resource available about how to
model
EIJ> multiple inheritance in non-multiple inheritance capable languages?
The right question would be "how to properly model those situations,
which
might (very often incorrectly) lead to multiple inheritance" ;)
That's unavoidable, unfortunately (cause I know it is hard to find a
proper example of MI, but this one is such).
Actually, the vast majority of MI usage in C++ is just a workaround for
its
lack of protocols:
Again, not my case. I have inheritance chains that can't be broken.
(i) if MI is used to define a common behaviour independent on the
"normal"
inheritance tree, then you want a protocol instead;
I know. I've used interfaces before.
(If you would need to add an implementation to a protocol -- which is
not
directly supported by ObjC -- you can use a category to easily
work-around
the problem.)
Well, yes I could use a category to work around adding implementation to
a protocol, but can I add class inheritance to a protocol in some way?
(ii) if MI is used to really combine functionality of more different
classes, you should carefully check your design first: there is a very
high
probablility you could re-design the system without that, gaining
simplicity,
code readability, and easier maintenance...
I've tried, but the problem is not trivial. The thing is that you could
do it by introducing more classes, and populating an already big class
model is not my idea of good.
(iii) ...though, there are very rare cases when this is vital. If so,
use
class embedding and message forwarding, through those patterns:
@interface Multiple:NSObject {
NSArray *embedded;
}
-aKnownMethod;
@end
...
@implementation Multiple
-init {
...
for (...) [embedded addObject:embedded_object];
...
}
-aKnownMethod { // just an example--in practice, you would probably
use a
smarter and more problem-oriented way to select the proper embedded
object:
NSEnumerator *en=[embedded objectEnumerator];
id receiver;
while (receiver=[en nextObject])
if ([receiver respondsToSelector:_cmd]) return [receiver
aKnownMethod];
}
...
To support forwarding of any unknown method, if you want to do that, use
forwardInvocation and methodSignatureForSelector (see NSObject
documentation
for a simple example).
This is what i had though about in the beginning but that does not give
me substituability. I might try it though, or something else combining
protocols and classes I've been thinking about.
Thanks a lot, useful advice here too, though too controversial around
the C++ issue. I know you don't like it, but ObjC does not have some
really usefull stuff from it, and its not that hard anyway.
Eduardo Jimenez