Inheritance Question

[joe.osowski]

I am extending Microsoft's webcontrols with a few extra properties and
methods.

Specifically TextBox and DropDownList and later probably more.

In a perfect world I would just add my methods to the WebControl class.
Or store the implementation in the Interface(if that was possible).
Unfortunately to my knowledge, I do not have access to this class. So
currently I defined an Interface that forces each of my custom classes
to implement a series of methods.

But the implementation is EXACTLY the same in every class. Which is
just silly. I perhaps could move the logic out to a static class, but
that is still kind of hack.

These methods are manipulating properties of the class they are a part
of, and they are doing the exact same thing in every class.

Any suggestions?

-Joe
http://phillylocal.com

 

[Derrick Coetzee [MSFT]]

I am extending Microsoft's webcontrols with a few extra properties and
methods. [...] So currently I defined an Interface that forces each of
my custom classes to implement a series of methods.

But the implementation is EXACTLY the same in every class. Which is
just silly. I perhaps could move the logic out to a static class, but
that is still kind of hack.

These methods are manipulating properties of the class they are a part
of, and they are doing the exact same thing in every class.

Hi Joe. It's interesting that you ran into this problem, because it's
exactly the issue solved by a language concept called "mix-ins" support by
some languages such as Ruby, D, and Python. More generally these apply to
any situation where you have a set of methods or properties that you want to
reuse in many classes and that only depend on a common portion of those
classes' interfaces. Unfortunately, C# does not support these, nor does it
support multiple inheritance, which could also help solve this issue in a
similar way.

If you're using C# 2.0, you can use generics to help solve this problem:
instead of implementing a subclass for each control, define a generic class
parameterized over control types like this:

public class ExtendControl<T> where T : WebControl {
public T Control;
public ExtendControl(T control) {
Control = control;
}
public void MyMethod() {
if (Control.SomeProperty) {
Control.SomeMethod(5);
}
}
// ...
}

This class acts as a wrapper for any of the WebControl subclasses. You can
access all methods of the base control through the Control property, and all
your new methods directly.

Finally, if you're not even using C# 2.0, there's still some hope. You can
write a class similar to the above, except that instead of using T it stores
an instance of WebControl. As long as you only use properties or methods of
WebControl in your methods, this will work fine. If you don't, you might
still consider a solution based on code generation: write a sort of
template, and use a script in your build process to produce a version of it
for each subclass.

Good luck with your problem. I hope this helps.

 

[joe.osowski]

Thanks

I know in C++ I could do multiple inheritance.

In Java I could just get the source for the API and rewrite it.

I think Microsoft, if they are going to keep .NET proprietary and not
open source. Needs to fix this.

 

[Derrick Coetzee [MSFT]]

I know in C++ I could do multiple inheritance.

In Java I could just get the source for the API and rewrite it.

I think Microsoft, if they are going to keep .NET proprietary and not
open source. Needs to fix this.

I understand your frustration, Joe, and I'm sorry that there's no particular
elegant solution in this case, but there are also tradeoffs to adding
language features such as these. In particular, multiple inheritance or
mix-ins could complicate the efficient implementation of the compiler and
runtime and possibly make the language more difficult to use for novices.
It's also almost never a good idea to "fork" the system API, because this
means you would have to distribute a redundant version of the API with your
application that cannot be shared between applications (increasing memory
footprint) and will not receive any future bug fixes to the original API. I
hope that at least in this case the delegation-based solutions are adequate
for your needs.