Welcome to Community Server Sign in | Join | Help

Seal This

Okay, I can appreciate that there's a time and place for sealed classes. I'm having a harder time appreciating the utility of sealed classes lacking a public ctor. Sure it means there's no way I can misuse something like System.Web.UI.CssStyleCollection out in the wild. Which also means there's very little shot at me even using CssStyleCollection out in the wild. Really, unless I'm using a CssStyleCollection that is built in to a existing WebControl or something derived from WebControl, it's a non-class.

So let's say I want to leverage prior framework art and expose a collection of styles in a composite control of my own malevolent design. And lets say this collection applies to multiple composed dynamic controls. I can't give the user the familiar CssStyleCollection to use, because I can't create one (unless I want to stash a couple shell Controls just to create usable CssStyleCollections--yes, this is silly, inelegant and inefficient, this is what I was nearly driven to think was reasonable). No, I have to expose NameValueCollections as my properties and later copy them by key into the render-time controls CssStyleCollections. Which works.

Would it be such a bad thing if all controls exposed inline styles as CssStyleCollections not just System.Web.UI denizens? Why seal this class? Obviously I'm venting about something specific, but it's not the first time I've been ticked about someone's decision that I was too dangerous to be let loose on their sealed class. I'm not trying to derive anything here, which is the silly part--I just want to create an instance of your precious little class and present the end control user with a consistent interface. That can't be all wrong.

Published Thursday, July 17, 2003 6:29 AM by grant

Comments

No Comments
Anonymous comments are disabled