Implementation of interface method is the same in all of the interface's implementations

[StevenECBrown]

I'm somewhat of a newbie.

This question has come up for me a couple of times, and it came up
again today: I have an interface IProviderFileVersionNumber that has
this method called GetOrderable. The implementation of GetOrderable
is _always_ exactly the same in each class that implements
IProviderFileVersionNumber, and always will be. It doesn't depend on
any particular details of the implementation. In a sense, I'd like to
put the code for GetOrderable in the interface, but of course I
cannot.

I could make the interface a public abstract class, except that I
think I need multiple inheritance. I have another interface
inheriting from IProviderFileVersionNumber called
IProviderFileVersionNumberOrderable (yes, I know these names are
getting annoyingly long), which needs to be fairly general. On the
other hand, I have specific implementations of these called
PerforceVersionNumber and PerforceVersionNumberOrderable. There is
lots of Perforce-specific stuff in PerforceVersionNumber that
PerforceVersionNumberOrderable needs to inherit, but as you can tell
from the names, PerforceVersionNumberOrderable also needs to be an
IProviderFileVersionNumberOrderable.

If I could multiply inherit classes, the answer would be obvious, but
I can't. Is there any way to avoid duplicating the same code for
GetOrderable across 10 different classes?

Thanks!
Steve Brown

 

[Jon Skeet [C# MVP]]

If I could multiply inherit classes, the answer would be obvious, but
I can't. Is there any way to avoid duplicating the same code for
GetOrderable across 10 different classes?

Create a class which has the appropriate code in and nothing else, then
create an instance of that class in each of your implementations of
IProviderFileVersionNumber. Proxy the call to GetOrderable to that
instance.

 

[Peter K]

Create a class which has the appropriate code in and nothing else, then
create an instance of that class in each of your implementations of
IProviderFileVersionNumber. Proxy the call to GetOrderable to that
instance.

Is it at all possible to do this in a smarter way? I have also reasonably
often come across this type of problem, and end up making a
"helper/utility" class. You still have to write the methods in the
implementations and redirect the call to the helper class - it would be
nicer if there was some sort of inheritance possibility.

/Peter

 

[Chris Nahr]

Is it at all possible to do this in a smarter way?

Not in C# as it stands, but Jon Skeet himself has thought of one:
http://msmvps.com/blogs/jon.skeet/a...-1-inheritance-is-dead-long-live-mix-ins.aspx

Here he also recommends abolishing inheritance altogether which IMO is
going too far. But an automatic proxy mechanism that generates simple
forwarder methods for interfaces would be very useful regardless.

 

[Marc Gravell]

I must brush up on my Reflection.Emit... there must be some
possibilities here... (hums merrily)

Marc

 

[Jon Skeet [C# MVP]]

Not in C# as it stands, but Jon Skeet himself has thought of one:
http://msmvps.com/blogs/jon.skeet/archive/2007/02/27/wacky-ideas-1-in
heritance-is-dead-long-live-mix-ins.aspx

Gosh, and here I was thinking no-one had actually read it

Here he also recommends abolishing inheritance altogether which IMO is
going too far. But an automatic proxy mechanism that generates simple
forwarder methods for interfaces would be very useful regardless.

I think "recommends" is a bit stronger than I'd put it. It was a wacky
idea that I pushed a little bit beyond sanity

 

[Marc Gravell]

Looks interesting... I'm not sure I'd jump on the "ditch inheritance"
wagon quite so quickly, but I see where you are coming from. What
would be interesting, however, is the provision of "proxies" as a
language extension, i.e. another tool at our disposal. I don't see how
this would be much different to the language support of closures /
captured variables etc - i.e. the compiler doing some tedious plumbing
for us at a stroke while still leaving the other tools intact.

Marc