Survey Results

First Prev Next

Re: Why avoid it?

Tom Archer22-Mar-02 7:19

Tom Archer

22-Mar-02 7:19

>>>
If you're programming for someone else, would you prefer explaining to her about the standard artifact in Java/C# for dealing with such situation (namely derive from an interface and delegate to a private member)?
<<<
Many times when I consult or program for someone, I'll never meet the people that will eventually maintain my code. Therefore, I take it as part of my responsibility to use techniques that are what I feel are standard. It's been my experience that MI is not something that the average programmer fully understands. You'll also note that people such as Bruce Eckel of the C++ standard committee shares this belief and also recommends against using it accept in very rare situations where there are no other options.

>>>
...but when it is the appropriate thing to do it can save your life. <<<
I agree

>>>
It goes along with C++ philosophy of treating programmers as grown adults and let them have access to all the tools available, dangerous as they may be.
<<<
This has nothing to do with treating people as adults and everything to do with the practical realities that part of my responsibility as a programmer is to turn in code that 1) gets the job done and 2) requires as little in terms of maintenance and learning as possible.

>>>
I know you're a C# guru, so I'd like to know whether there is a pragmatic reason for leaving MI out of this language. Does it make reflection or some other feature harder to implement? That could be a reasonable case against MI.
<<<
If you look closely at C# you'll see many situations where the language left out features that are C++ because the risk/reward ration was deemed to high. Case fallthrough is a perfect example of this. Most experienced developers are not going to commit an error with this and love having it at their disposal. However, as Eric Gunnerson explained to me, its not technically needed (as there are other ways to accomplish the same thing) and only serve to get less experienced programmers into trouble. Therefore, while you might very well be a highly-competent programmer who knows MI inside/out, the simple fact is that it gets too many developers into trouble to be worth its risk with its inclusion in the language.

Cheers,
Tom Archer
Author, Inside C#

Re: Why avoid it?

Matthew Adams23-Mar-02 7:44

Matthew Adams

23-Mar-02 7:44

I think that IS A is *always* a contentious design decision. BEHAVES LIKE A is (almost) always a more conservative and pragmatic analysis. You should work on the assumption that the latter is the case, and only solidify to an IS-A relationship if you prove, late in the design process that the relationship holds.

Matthew Adams
Development Manager
Digital Healthcare Ltd

It's all George's fault

Nish Nishant17-Mar-02 15:05

Nish Nishant

17-Mar-02 15:05

We were having nice simple polls like do you like the new VS.NET UI or how many of you like C# or some such nice simple stuff.

Now it's all templates and multiple inheritance.

And that Georgie Boy is not even to be seen.

Nish Wink | ;-)

My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold

www.busterboy.org

Option	Votes	%
Yes, I often derive from multiple classes	135	13.80
Yes, I occasionally derive from multiple classes	376	38.45
Yes, I use classes that are derived from multiple classes (but don't create these classes myself)	90	9.20
No - I see no need	192	19.63
No - the language I use doesn't support MI	44	4.50
No - I intentionally avoid MI.	141	14.42
Total	978	100%

Multiple Inheritence [Edit]