Re: Question
Re: Question
- Subject: Re: Question
- From: "Clark S. Cox III" <email@hidden>
- Date: Mon, 3 Dec 2001 23:15:16 -0500
On Monday, December 3, 2001, at 09:37 , Eduardo I. Jiminez wrote:
On Sunday, December 2, 2001, at 11:58 PM, Greg Titus wrote:
You are asking the wrong question, I think - at least, it's the wrong
question if you want a good answer. The way you are asking it you are
almost guaranteed to get an unsatisfactory answer and to come away with
the opinion that Objective-C and Java lacking multiple inheritance is a
_bad_ thing. :-)
Well, I definitively didn't mean that, pardon my English...:). The thing
is that the classes are rather complex, and I already know protocols won'
t work for me. From the solutions I've read on the list (not many, just a
lot of flaming), one that could work is composite objects. I am going to
make some comments, and please, keep it to yourselves if you don't agree
(I mean the rest of the people on the list that are just waiting to flame
others based on their PERSONAL opinions).
I have a class model that I need to implement for a MacOS X application
whose interface will be written in Cocoa. The class model is not
changeable, and like it or not, it has multiple inheritance in it because
it makes a lot of sense. I don't think that 150+ classes is a flawed
system, but it is complex. It is a system with several components and
functionality very well distributed among many simple objects that map to
real entities in the participating processes and systems.
IMHO, if the class design cannot be changed, then there is nothing
wrong about implementing the back-end in C++, and doing the front-end in
Obj-C. That's what the Obj-C++ compiler is there for. This way, you gain
all of the UI features of Cocoa (giving you app a consistant feel), and
you get a very portable codebase. You could port it to Linux or Windoze by
adding another frontend (or to GNUStep by recompiling -- when GNUStep is
completed, that is :).
As an experienced programmer and a growing software engineer, I recognize
the importance of clean, clear, bug-free code. I don't like patches and I
love compiler checks cause they can help you have really good code. This
is a reason I like C++. I like it, I love it. Those guys who seem to hate
it because it is difficult simply don't understand it. I would recommend
you two excellent books on how to make your life easy (and I mean easy,
very very easy): Effective C++ and More Effective C++ from Scott Meyers
(Addisson Wesley). My particular design does not have (nor it is going to)
any diamond shape inheritance, and operations from classes are entirely
different.
When many people hear "multiple inheritance", the automatically think
"diamond shape inheritance", which is, IMHO, a design flaw. But from what
you've posted, you seem to be implementing a mix-in style approach:
class Shape
{
int numberOfSides;
};
class MIsColored
{
Color color;
};
class MIs3D
{
float depth;
};
class ColoredShape : Shape, MIsColored;
class 3dShape : Shape, MIs3d;
class Colored3dShape : Shape, MIs3d, MIsColored;
Which, if carefull implemented, I don't see very many problems with.
Now, back to the point. Sure, I could fix the problem by coding a
composite object (can't use protocols because protocols cannot inherit
from classes, right?) with an union of both superclasses' interfaces,
forwarding calls to a couple of objects that represent each state of the
multiple superclass object, right?.
Correct.
However, this way I would not gain type equivalence,
Correct
having to use "id" as parameter type whenever I need to receive an
object like this one.
You could use:
id<MyProtocol1,MyProtocol2,...>
and still get *some* compile-time checking.
Sure ObjC is great and it will tell me if I'm doing someting wrong in
runtime, but I really prefer C++'s way (that is, strong typing, where I
can specify what I want in) from a code clarity point of view. Also I
have some objects that could use operators, a great advantage of C++
(also for code clarity in structure navigation, object comparisons and
combining). Another reason NOT to use ObjC its because it is not portable.
I will not be able to use that code in the future to port the
application to another system, like Solaris, Linux, Windows or whatever.
But if my basic framework is in C++, I can use it anywhere.
Gee, I should have read the whole message before starting my reply :)
You don't really want to model multiple inheritance, per se, you want to
model some specific kinds of relationships between your classes and you
are used to using multiple inheritance in C++ to do so.
Exactly. That is what I want.
I could go into a lot of detail about the different kinds... (One quick
example: one use of MI in C++ is a base class with all virtual members
and then many other classes inheriting from that class as a way to deal
with many different types of otherwise unrelated objects that all
implement the same set of methods. In Java you'd use an interface
instead. In Objective-C you'd use either a formal or informal protocol -
and which was best would depend on other things. That's the very easiest
example because it's an area where I can point to a specific language
feature which is a much better fit for the design pattern than MI.) But
we'd quickly get bogged down in all the different ways to do things
described in very general and nearly useless terms, and I'd still
probably miss some of the patterns that end up being in your design.
This is not my case. I though of that before, but there is a 4 level
inheritance chain I can't break. I can't put a protocol (or interface) in
the middle. There are ways to achieve multiple inheritance through
delegation, but the papers are not available online. I will search the
ACM to see what i find.
If you are willing to go into some more detail about what your class
design is trying to accomplish we (I) could probably be more helpful.
My basic problem is the fact that I would really hate to loosen type
checking in order to get around the problem. As I said again, I like the
compiler to do work for me. Is it so bad to integrate C++ with ObjC?.
No
Does it cost more to the application in terms of runtime structures?.
Not really, especially if you are only using your own classes, and the
STL (which are all inline), then you don't even have to link with libstdc+
+.
--
Clark S. Cox, III
email@hidden
http://www.whereismyhead.com/clark/
| References: | |
| | >Re: Question (From: "Eduardo I. Jiménez" <email@hidden>) |