Psuedo-multiple-inheritance with extension methods on interfaces in C#?

views:

509

answers:

+3 Q:

Psuedo-multiple-inheritance with extension methods on interfaces in C#?

I was thinking that with extension methods in the same namespace as the interface you could get a similar effect to multiple inheritance in that you don't need to have duplicate code implementing the same interface the same way in 10 different classes.

What are some of the downsides of doing this? I think the pros are pretty obvious, it's the cons that usually come back to bite you later on.

One of the cons I see is that the extension methods can't be virtual, so you need to be sure that you actually do want them implemented the same way for every instance.

+3 A:

The problem that I see with building interface capability via extension methods is that you are no longer actually implementing the interface and so can't use the object as the interface type.

Say I have a method that takes an object of type IBar. If I implement the IBar interface on class Foo via extension methods, then Foo doesn't derive from IBar and can't be used interchangeably with it (Liskov Substitution principle). Sure, I get the behavior that I want added to Foo, but I lose the most important aspect of creating interfaces in the first place -- being able to define an abstract contract that can be implemented in a variety of ways by various classes so that dependent classes need not know about concrete implementations.

If I needed multiple inheritance (and so far I've lived without it) badly enough, I think I'd use composition instead to minimize the amount of code duplication.

tvanfosson 2009-05-30 14:56:28

Could you explain "then Foo doesn't derive from IBar and can't be used interchangeably with it"?If I have public class Foo : IBar, wouldn't any I be able to pass in a Foo anywhere an IBar is expected? Or did you mean something different?I realize that it ceases to function as an interface. Functionally I envision it acting more like a concrete base class with no virtual methods than an interface. (Whether that's a good idea or not is possibly a separate question, but it seems useful to keep DRY)

Davy8 2009-05-30 15:18:18

And most of the time I don't really see too much need for multiple inheritance, but there's one portion of code at work that seems like a mess with repeated code all over the place implementing the same interface on literally 10-20 different classes with all the same code, and it couldn't be put into a base class because they already derive from another base class that has methods common to a different interface.

Davy8 2009-05-30 15:22:14

If Foo derives from IBar then it needs to have instance methods, not extension methods that implement IBar. Are you expecting to delegate these methods to the extension methods? I was assuming that the implementation was provided solely by the extensions. If you are doing delegation, then I think composition from base classes implementing the desired interface functionality is more preferable than extension methods. Perhaps you could provide the functionality using the decorator pattern.

tvanfosson 2009-05-30 15:38:50

Oh, you're right, Foo would still need to implement the methods of IBar. (I haven't actually tried this, just thinking about it). What about if IBar didn't actually contain any methods in the interface. All the methods are extension methods on an empty interface.

Davy8 2009-05-30 16:00:53

If the extensions are on the interface, not the class, then how would you use them from Foo objects -- casting? It still seems very hackish and an abuse of extension methods to me. I think extension methods are best left to adding functionality to classes that you don't control.

tvanfosson 2009-05-30 16:04:00

You wouldn't need to cast them. If Foo implements IBar you can use any method on IBar on Foo, otherwise nothing in LINQ would work without casting to IQueryable or IEnumerable first. I agree it's probably not best practice but it can be useful and is better than copy/paste implementations all over the place.

Davy8 2009-05-30 21:55:14

A decent way to think about this is that instance methods are something done by the object, while extension methods are something done to the object. I am fairly certain the Framework Design Guidelines say you should implement an instance method whenever possible.

An interface declares "I care about using this functionality, but not how it is accomplished." That leaves implementers the freedom to choose the how. It decouples the intent, a public API, from the mechanism, a class with concrete code.

As this is the main benefit of interfaces, implementing them entirely as extension methods seems to defeat their purpose. Even IEnumerable<T> has an instance method.

Edit: Also, objects are meant to act on the data they contain. Extension methods can only see an object's public API (as they are just static methods); you would have to expose all of an object's state to make it work (an OO no-no).

Bryan Watts 2009-06-04 01:57:46

I probably worded the question badly, but I'm basically meaning to not treat it as an interface. The interface is merely the technical means of accomplishing the task, which is code-reuse and implementing a poor-man's multiple inheritance in a language that does not support it.

Davy8 2009-06-04 02:41:34

Ok, I see what you are asking. You would ultimately like to attach behavior to classes which "opt in" by implementing an interface. Multiple interfaces = multiple behaviors = multiple inheritance. Good reasoning, but what does it mean? You still have to expose an object's state so extension methods can work with it. But now anyone can see that state, so no encapsulation. Even then, the method will only get an IBar, which has no members, and thus isn't very useful. What could the extension methods do? As @tvanfosson said, composition is your best bet.

Bryan Watts 2009-06-04 04:54:54

ansaurus

tags:

views:

answers:

Psuedo-multiple-inheritance with extension methods on interfaces in C#?

related questions