Multiple-inheritance, composition and single responsibility principle in .NET
.NET is often chided by C++ developers for failing to support multiple-inheritance. The reply is often Favor object composition over class inheritance – a mantra chanted from everywhere including the opening chapters of the Gang of Four’s Design Patterns book.
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
public class CustomerPriceList : IList<ProductPrice> {
private List<ProductPrice> productPrices = new List<ProductPrice>();
public Customer Customer;
}
Implement interface
Visual Studio offers some assistance where you can choose Implement interface IList
public class CustomerPriceList : IList<ProductPrice> {
private List<ProductPrice> productPrices = new List<ProductPrice>();
public Customer Customer;
public int IndexOf(ProductPrice item) {
return productPrices.IndexOf(item);
}
public void Insert(int index, ProductPrice item) {
productPrices.Insert(index, item);
}
public void RemoveAt(int index) {
productPrices.RemoveAt(index);
}
public ProductPrice this[int index] {
get { return productPrices[index]; }
set { productPrices[index] = value; }
}
public void Add(ProductPrice item) {
productPrices.Add(item);
}
public void Clear() {
productPrices.Clear();
}
public bool Contains(ProductPrice item) {
return productPrices.Contains(item);
}
public void CopyTo(ProductPrice[] array, int arrayIndex) {
productPrices.CopyTo(array, arrayIndex);
}
public int Count { get { return productPrices.Count; } }
public bool IsReadOnly { get { return ((IList)productPrices).IsReadOnly; } }
public bool Remove(ProductPrice item) {
return productPrices.Remove(item);
}
public IEnumerator<ProductPrice> GetEnumerator() {
return productPrices.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator() {
return ((IEnumerable) productPrices).GetEnumerator();
}
}
This is a lot of effort for a cluttered solution.
Use inheritance to subclass List
public class CustomerPriceList : List<ProductPrice> {
public Customer Customer;
}
Small amount of code but not an option if you have a class hierarchy in place or need to implement multiple interfaces.
Expose IList property directly
public class CustomerPriceList : IListable<ProductPrice> {
private List<ProductPrice> productPrices = new List<ProductPrice>();
public Customer Customer;
public IList<ProductPrice> ProductPrices { get { return productPrices; } }
}
This works but means CustomerPriceList can not control any of the IList implementation such as validation.
Methods may also start accepting IList
Refactoring away from this at a later date would require a IList
Introduce interface to declare IList available
Add an interface that signifies a IList
public interface IListable<T> {
IList<T> GetList();
}
This is a similar pattern to that of IEnumerable
public class CustomerPriceList : IListable<ProductPrice> {
private List<ProductPrice> productPrices = new List<ProductPrice>();
public Customer Customer;
public IList<ProductPrice> GetList() {
return productPrices;
}
}
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:
public class CustomerPriceList : IList<ProductPrice> goto productPrice {
private IList<ProductPrice> productPrice = new IList<ProductPrice>();
public Customer Customer;
}
This would signify to the compiler that all IList
[)amien
5 responses