On Wed, 28 Feb 2007 08:05:47 +0800, Paul Werkowitz
<ne********@primaprogramm.dewrote:
[...]
It is simply annoying to have to write things like
//-----------------------------------------------------------------
// boBindName
//
[
Bindable (true)
, Category ("QFC")
, Description ("Feld/Property, an das gebunden werden soll")
]
public string boBindName
{
get { return mBoBindName; }
set { mBoBindName = value; }
}
over and over again and identical in all controls. This is stupid, and
exactly this is one of the things MI was invented for.
I agree that having multiple inheritance would help address that.
However, there are other solutions that don't involve copying and pasting
the interesting code over and over.
For one, you could instead implement a helper class that all of your
derived classes include and expose as a property. Then you only have to
add the member (field) to the derived classes, along with a simple
property to expose the member. The longer code just needs to be written
once. This is, of course, a lot more maintainable as well; if you have to
change the shared functionality, you can change it just once rather than
having to revisit several copies of a 100 line block of code.
A similar solution would be to declare an interface. Then rather than
exposing your added functionality as a property, it's simply an interface
that the derived classes expose. This works more like multiple
inheritance, without many of the problems of multiple inheritance.
That said, I have also found that often times when I find that the
language seems to be impeding my progress and preventing me from doing
something I want to do, then whatever I am trying to do turns out to be a
poor design decision in the first place. There's usually an alternate
method that is completely different from the approach I start out with,
and which works better in the given language. In many cases, it turns out
to be more efficient and more maintainable as well.
In addition, my experiences with multiple inheritance in C++ have led me
to feel that multiple inheritance has more drawbacks than it does
advantages. Code I've dealt with that has multiple inheritance invariably
is harder to work with, buggier, and often creates strange ambiguities
that are difficult (or at the very least, awkward) to resolve.
It may be that you are dealing with a rare case in which you truly need
multiple inheritance. However, I suspect that it's more likely that if
you simply approach the problem from a slightly different vantage, you may
find an alternate solution that works just fine and which fits better into
the .NET paradigm, and which does not require that you copy and paste your
code over and over. My experience has been that copied and pasted code is
one of the very worst transgressions a programmer can do. I've yet to run
into a situation where interesting code (that is, anything more
complicated that a declaration or reference or something like that)
actually does have to be copied and pasted.
Pete
