Framework Design Guidelines: Sealed Classes

infoblog » Framework Design Guidelines: Sealed Classes

infoblog » Framework Design Guidelines: Sealed Classes — Tue, 20 Jan 2009 06:41:07 GMT

PingBack from http://blog.a-foton.ru/index.php/2009/01/20/framework-design-guidelines-sealed-classes/

re: Framework Design Guidelines: Sealed Classes

daniel_lidstrom — Tue, 20 Jan 2009 13:11:22 GMT

This looks dangerous to me. Unless OrdersQueue really IS-A MessageQueue, that is. In C++ at least, deriving from a concrete class should be private (my experience).

Can't this be solved with extension methods instead? Convenience constructors can be provided with factory methods.

Regards,

Daniel Lidström

Stockholm, Sweden

re: Framework Design Guidelines: Sealed Classes

Rune Sundling — Tue, 20 Jan 2009 13:42:08 GMT

Thank you for putting this in the guidelines!

The often extreme focus Micrsoft has had on babysitting developers by sealing every class is a quite annoying practice.

re: Framework Design Guidelines: Sealed Classes

Steve Dunn — Tue, 20 Jan 2009 16:54:48 GMT

Leaving types unsealed is great, although I'm not sure about promoting the use of inheritance without first suggesting composition as a better alternative.

Also, Phil's comment about making key members virtual and promoting the use of the Template Method pattern seems a tad dangerous; what are 'key members'? Anything public? Anything protected? Surely the key members are specific to why you're deriving from the class in the first place? I'd hate to see lots of abstract classes introduced into the Framework to facilitate the Template Method pattern.

re: Framework Design Guidelines: Sealed Classes

AMO — Wed, 21 Jan 2009 09:56:05 GMT

Interesting post. However, the title of the post gave me the expectation of providing a guideline on when to write sealed classes, not unsealed classes.

re: Framework Design Guidelines: Sealed Classes

Sajida — Thu, 22 Jan 2009 10:41:33 GMT

Dear Sir/ Madam,

Based in UAE, I am currently employed as a Country Manager at PMDC( Property Management and Development Company).

I have a total of 8 years experience in the property field and I believe that the skills I have acquired in the course of my professional and educational experience will be valuable assets for your organization.

Attached are my contact details and detailed CV for your review. I would appreciate the opportunity to speak with a member of your organization and see the way to help and join you. Thank you very much for your consideration.

Looking forward to your replay.

Best regards,

Sajida Ismail

Dubai, Uae

Tel: 00971- 5020-23087

arwawail@hotmail.com

Brad Abrams : Framework Design Guidelines: Sealed Classes

DotNetShoutout — Fri, 23 Jan 2009 18:51:48 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Framework Design Guidelines: Sealed Classes

Dean Chalk — Sun, 25 Jan 2009 11:00:48 GMT

On of the big issues with leaving classes un-sealed and members abstract or virtual is performance.

The CLR will perform a special set of optimisations for a class if it's sealed to make it super-fast (the CLR doesnt have to worry about polymorphic access by super-classes). Also if a member's not virtual, the CLR can perform optimisations for it too.

Classes should be sealed by default and then unsealed by design.

Static classes are particularly performant, because they are compiled as abstract and sealed, exposing on static members.

Dean

re: Framework Design Guidelines: Sealed Classes

Jon Skeet — Mon, 30 Mar 2009 21:33:37 GMT

Ick, no.

I'm one of the crowd that think C# should seal classes by default. Inheritance is a powerful tool, but can be a pain if it's not thought about carefully. If you don't *design* for inheritance, you shouldn't *permit* it. Designing for inheritance is hard, and limits your implementation freedom later. Do you really want to document everywhere that the implementation calls a virtual method? You can't change your mind later - someone may be depending on that behaviour. (If you don't document it, they shouldn't depend on it but it becomes unexpected; if you *do* document it, you'd be breaking the contract.)

If you want to be able to use a test double for a class, make it implement an interface and use the interface as the dependency.

If you want to "add" methods to simplify the API, but without adding any extra data and only *using* the public API, use extension methods - they're great for that.

Inheritance should be for *specialization* IMO, which doesn't really cover either of the reasons given here.

For a more intelligent explanation of my point of view, read CLR via C# or Effective Java, both of which are written by smarter people than me :)

Jon