Earlier this week there was an interesting discussion started by Scott Hanselman on making things public or private by default and the risks of making things public in a framework and developers later extending on those and breaking things. Ayende weighted in with his own thoughts on the matter arguing for more public stuff and letting the user make his own decission about the risk involved.
I can see arguments for both sides. However, at some point the discussion seems to be mixing two things: Extensibility and Usage. So, here's my (very simplistic) view on the topic:
- It's ok to deny extensibility of a class either implicitly (by not making anything virtual) or explicitly (by making it sealed, this being preffered). To be honest, I rarely make things virtual unless I explicitly wanted meant to use the class as a base class of sorts.
- It's not OK to make everything internal. Doing so causes a lot of pains for developers looking to extend through usage and not through inheritance/implementation, which is quite a powerful technique. Public classes coupled with explicit, well-designed, extensibility hooks is a great thing to have.
In particular I mention number 2 above because I've been bitten by it several times: I'm using a framework and class library that has great extensibility hooks that get me 90% to where I need to go, and then the other 10% could be accomplished by calling into something the library has already implemented but which I can't do because it's internal; leaving no choice but to reimplement a lot of functionality that was there already. That's bad, imho.
A specific example I encountered recently with WCF: The extensibility interfaces are great and can really get you far into your extensions (particularly the behavior extensions are the bomb!), but I'm not sure I'll be able to do something I need to do without writing huge ammounts of code just because the DispatchBuilder and Invoker classes are internal, which sucks big time.
Technorati: Design, Extensibility, .NET, WCF
