- Can cause problems by users of your framework who don’t understand it.
- Virtual members cannot be inlined.
The first issue is very simple, if a programmer do not understand what a virtual method is, he has no business touching. This is such a basic gap that you just can't fill with trying to protect the user. Check the Daily WTF story about such a programmer.
The second issue is a more serious matter, and is actually the reason that in .Net 2.0 List<T> has no virtual memebers. My personal opinion in this matter is probably already known, this is the wrong design desicion to make. Especially since so much of .Net 2.0 (controls, data binding) assumes that you are working with List<T> and not with the interface.
The JIT is capable of inline interface methods, as a matter of fact, so if you think that you class will see as much perf critical code paths as List<T>, make the methods non virtual and always use the interface. One of the big things about OO is that you can use polymorphism to cleanly modify the actions of the system. You should always leave a way for a programmer to come in and change what the system does.
A simple example: I want to use WithEventsList<T>, which will raise Added, Removed, Cleared events at the appropriate times. Not a hard thing to do, except that I can't use List<T> as a base class, all those methods are non virtual, I have no way to extend the functionality of the class.
Speaking about interfaces, this is what Raymond had to say about them;
- Use abstract classes, not interfaces, to decouple contract from implementation.
I am pretty sure that I don't agree with the above, but I am not sure what the meaning is, Raymond, can you clarify?