It seems the debate is still going. This time, it's between Scott Hanselman and Paul Stovell. Scott (and Keith Pleas) did a presentation at Tech Ed this year about building enterprise frameworks. Scott had a slide basically saying that when you build a framework, you need to be careful about how you allow your users to extend it. He says to use internal and sealed more and only open it up as people request it. He does a good job of defending his position, using real life examples in his day to day job.

Paul, on the other hand, doesn't agree with Scott's assessment, maintaining that he gets routinely frustrated looking at the .NET framework and seeing the code he needs hidden in?an internal or sealed class.

It's an interesting debate. I'm torn on where I come down on it, because I can see benefits of both sides. Having built a framework, I've thought about both sides of it, and right now, I fall in the open inheritance camp. At least based on what we delivered in the framework - everything is public, and can be potentially overridden. Oh yeah, and since the framework is a set of templates, the generated source is delivered with it.

And maybe that's the difference. If I was required to deliver a framework in DLL format, I might have a different view. Then I would be responsible for how every project used every portion of the framework. That could be tough over time, especially as new versions get released. By delivering source, you get a "snapshot framework" - you get it from a point in time, and from there, you have choices. First, don't modify the generated code or templates in hopes that you can get updates to the framework as we release new ones. Second,?change just the templates so you only have to worry about merging in template changes if you want to go to a new release.?Lastly, change the generated code and go off on your own. No matter what a user decides, we're not necessarily maintaining the framework for that project anymore. We're now maintaining it for future projects. So, since you get the source, we can be as open as we want to be - you get the source anyway, so even if we closed it up, you could just as easily open it back?up.

But when you release a framework as a standalone thing, it's a little tougher to take the plunge and just open it up. You now are responsible for the way everyone uses it, and if they use it in a "new and interesting way" (read, they break it), you have to fix it. And when you have to fix it, you'll be much more judicious about how much you expose. Reading Paul's post, it's obvious what view he's coming from - a user of the framework.?And when you think about that, it's obvious where the argument is going. He wants to be able to get to the inner workings of anything he's doing - because nothing will ever be a 100% exact match. On the other side is Scott.?He has to build and maintain the framework, so he's going to be much more stringent in how he opens it up. Same with the .NET framework - if it was wide open, it probably wouldn't be nearly as accepted as it is today, just because of the ways it would get extended and the reputation it would get for not working because someone broke the internals of it.

Agree or disagree, just seeing the discussions brings about a lot of great ideas and different ways of thinking, which is good for all of us.

Technorati Tags: Designed+Inheritance | Open+Inheritance