Composition over Inheritance: Custom Collections
November 8, 2012 Leave a comment
Composition over inheritance is a known but unfortunately not very well understood OOD principle.
All too often I see code like this:
public class MyFooList : List<Foo> { /* .. */ }
or this:
public class MySomething
{
public List<Foo> Foos { get; set; }
}
The derived class adds a method or two. Maybe a property. And it carries all the weight of the super-class List<T>. The property of type List<Foo> is there for anybody to fill with content of unverified qualities. Why?!
List is a powerful class but it does not give you any control over the objects that are added to it. What if your custom collection needs to protect invariants like “You can only add Foos with a Bar > 7?” Or you can only append to your collection but not remove objects from it. There is no easy way to model this when you are inheriting from List<T> or providing raw lists as part of your API.
If you don’t need the majority of the 30-some methods and the ~10 properties why would you show them? They just blur your interface. A simple custom collection that only offers what your consumers need to know is simple enough to write. If you implement IEnumerable<T> you can even unleash all the power of LINQ to select items from your collection.
If you have many or very complex invariants encapsulate them in validators to protect your collection. Let the collection tell its consumers about the rules a Foo instance violates when they are trying to add it to the collection.
[TestMethod]
public void Should_NotifyOnViolatedInvariants()
{
var collection = new MyFooCollection(new IFooValidator[] { new NotNullValidator(), new MinBarValidator(7) });
IFooValidator violatedInvariant;
Assert.IsFalse(collection.Add(null, out violatedInvariant));
Assert.IsInstanceOfType(violatedInvariant, typeof(NotNullValidator));
Assert.IsFalse(collection.Add(new Foo() { Bar = 1 }, out violatedInvariant));
Assert.IsInstanceOfType(violatedInvariant, typeof(MinBarValidator));
Assert.IsTrue(collection.Add(new Foo { Bar = 8 }, out violatedInvariant));
}
public class MyFooCollection : IEnumerable<Foo>
{
private readonly IEnumerable<IFooValidator> validators;
private readonly List<Foo> foos;
public MyFooCollection(IEnumerable<IFooValidator> validators)
{
this.validators = validators ?? new IFooValidator[0];
this.foos = new List<Foo>();
}
public bool Add(Foo foo, out IFooValidator violatedInvariant)
{
violatedInvariant = this.validators.FirstOrDefault(v => v.ViolatesInvariant(foo));
if (violatedInvariant == null)
{
this.foos.Add(foo);
return true;
}
return false;
}
public IEnumerator<Foo> GetEnumerator()
{
return this.foos.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
}
public interface IFooValidator
{
string Description { get; }
bool ViolatesInvariant(Foo foo);
}
public class MinBarValidator : IFooValidator
{
private readonly int minBar;
public MinBarValidator(int minBar)
{
this.minBar = minBar;
}
public string Description
{
get { return string.Format("foo.Bar must be greater than {0}", this.minBar); }
}
public bool ViolatesInvariant(Foo foo)
{
return foo.Bar <= this.minBar;
}
}
public class NotNullValidator : IFooValidator
{
public string Description
{
get { return "foo must not be null."; }
}
public bool ViolatesInvariant(Foo foo)
{
return foo == null;
}
}
public class Foo
{
public int Bar { get; set; }
}
You are still using the list under the covers. But your custom collection (just a couple of lines long!) is now stream-lined to only provide the functionality that is really needed. If you expose a raw List<T> anybody can modify the contents of that list. There is no way to enforce the collections invariants. With the custom collection your intentions became clearer and you made using your API safer. Isn’t that worth the bit of extra effort?
Outlawtrail - .NET Development 