If the accepted mantra is that your object should expose interfaces and delegate the implementation of those interfaces elsewhere then it could really do with some better support than .NET currently offers especially where the interface comprises more than a member or two.

Consider the following fragment of a class for customer price-lists (properties and methods omitted). We decide to support IList<ProductPrice> so that consumers of our class can add, remove and iterate over the prices in a familiar manner (principle of least surprise).

Implement interface

Visual Studio offers some assistance where you can choose Implement interface IList<ProductPrice> which gives you all the method definitions with the very unhelpful body of throwing an exception of “This method or operation is not implemented”. It requires some work to fill in all these definitions to something that works:

This works but means CustomerPriceList can not control any of the IList implementation such as validation.

Methods may also start accepting IList<ProductPrice> instead of CustomerPriceList because developers imagine the parts to be more decoupled than they actually are and are encouraged to code to interfaces not concrete classes.

Refactoring away from this at a later date would require a IList<ProductPrice> wrapper than delegated calls back to the containing class to prevent an interface-breaking change.

Introduce interface to declare IList<ProductPrice> available

Add an interface that signifies a IList<ProductPrice> can be obtained by calling the named method, e.g.

public interface IListable<T> {
IList<T> GetList();
}

This is a similar pattern to that of IEnumerable<T> and IEnumerator<T> whereby one interface signifies the availability of the other. In this example our class would look like:

Which is less code, a closer adherence to single responsibility principle (SRP) and the ability to change without breaking the interface although it still does nothing to prevent passing IList or IListable interfaces where CustomerPriceList would be more suitable. An IPriceList class could be introduced although it starts to feel like abstract infinity.

Improved support from .NET

I’d really like to see .NET improve on the support for interfaces and composition, like perhaps the following:

Hey, and you’ve found a use for the ‘goto’ keyword again. That in itself has to be a positive thing ;)

I think like all mantras the ‘compose over inherit’ principle is correct in moderation. There are plenty of scenarios where composition leads to harder to maintain code, simply because in just about all languages it has to be manually wired up. This is of course its power as well, and I’m not sure you can get the full benefit of the technique without incurring this. At the very least I think you’d need to be able to direct the delegation via a factory method for the contained object (lazy creation) to avoid hard-coding the composed type.

Many modern C++ techniques also echew inheritence in favour of templated composition through Policy Based Design. Again this works very well for some things, particularly low-level utility classes as opposed to higher-evel library APIs. Each technique has its place.

I’m failing to see the big accomplishments of this post. A big issue to me is the fact that when you don’t implement the interface you lose your ability to validate and monitor the actions taking place with the collection. If someone calls Add() your class doesn’t have any hooks to validate that added reference. I think in this case actually implementing the interface on your class is relatively minor yet offers a lot of added benefit, such as being able to reject invalid assignments.

Plus, I was confused by something else. How is using a read only property any different from using a get method to return the collection? I fail to see how one approach is superior to the other. They both compile down to the exact same thing. The property becomes a get_ method and the method stays as a method of your name. How is this any different? I hope you don’t mean the names are different so it doesn’t have to be a list of product prices. If that is the concern change the property to List, and you have the same result. Is there something I’m missing?

What I’m proposing with this post is compiler magic that would signal that an interface a class claims to support should be automatically wired up to a private instance variable where no specific implementation of a method or property exists in the class.

Having a get method isn’t any better than a read only property, I was just closely following what the IEnumerable / IEnumerator pattern is to see what the result would look like.

I think we are after the same thing. We want to be able to define a class, say it supports interface X and that we will be forwarding all methods and properties for that interface to our own private method except any we specifically write – in our case Add.

Other alternatives to the specific Add on collection problem you mention would be to force the collection property to be of a listening type we can hook into or to internally hold the concrete collection but expose it out through a proxy object on one of our properties that calls us back using internal methods.