I ran into a struggle choosing between interface and an abstract class, and finally solved it with something I already knew but seriously overlooked until the good folks at stackoverflow.com reminded me.

I am writing a drawing library that picks up vertex and transformation data from IRenderable objects to be rendered to the screen. I also want to add a feature where objects can be nested in what I call a skeleton-bone hierarchy.

public interface ISkeleton
{
    IEnumerable<IBone> Bones { get; }
    void Attach(IBone bone);
    void Detach(Ibone bone);
}

The idea is that library users can create objects that implement this class so that the library can detect that it is a skeleton and pick up the bones for rendering as well.

There is one problem though. For the bones to render correctly, I need to tweak the bone transform each time it is Attach() or Detach() and this tweak is internal to the library that I am creating, i.e. library users will not know how to apply the tweak. As a result, it seemed like I needed an abstract class instead.

public abstract SkeletonBase
{
    public IEnumerable<IBone> Bones { get { return mBones; } }
    private List<IBone> _mBones = new List<IBone>();
    public void Attach(IBone bone)
    {
        bone.TweakTransform();
        _mBones.Add(bone);
    }
    public void Detach(IBone bone)
    {
        bone.RevertTransform();
        _mBones.Remove(bone);
    }
}

An abstract class would certainly fulfill the function of an interface, and also the requirement of internal code implementation of the Attach() and Detach(). But it also introduces several drawbacks due to the fact that C# does not allow multiple inheritance. For example, if I had another abstract class, the user has to inherit twice instead of once before getting the functionality of both abstract classes. Also in an Object Oriented Programming point of view, I feel it is inapproperiate for the library to have a SkeletonBase class but only an IRenderable inteface when this is a drawing library. It just felt really wrong.

Solution
The way to look at this is to find the the smallest unit of objects that can be created to encapsulate the internal library code required. In this case, the smallest unit of object is a BoneCollection.

public sealed class BoneCollection : IEnumrable<IBone>
{
    private List<IBone> _mBones = new List<IBone> _mBones();
    public void Attach(IBone bone)
    {
        bone.TweakTransform();
        _mBones.Add(bone);
    }
    public void Detach(IBone bone)
    {
        bone.RevertTransform();
        _mBones.Remove(bone);
    }
}

public interface ISkeleton
{
     BoneCollection Bones { get; }
}