Designing great frameworks training: Designing Inherence hierarchies


Continuing on the weekly series, today we posted the session on Designing Inheritance hierarchies.  Thanks for watching the last week’s session on Member Types and coming that chat… If you missed it there will be a chat transcript posted soon.  

 

I’d love to hear your feedback on the session.. keep the comments coming! 

 

A couple of notes I made as I reviewed the material recently:

 

Slide 5: Have you seen code in your company where someone just did a throw new Exception (“”);  Or better yet, have you tried to debug code that gives you zero information by using on of those exceptions?

 

Slide 6: In case it is not clear, I think “non-virtual” is BY Far the right default…treat with suspicion all abstract and virtual types

 

Slide 8: Ok, pause it here and actually try to figure out what gets printed out… Don’t listen to this slide until you have your answer… I have seen some senior folks get this wrong. 

 

Slide 10: Just to emphasize that, if you are in MSDN reading the docs on a virtual member and the contract is not CLEARLY specified please click on that little “send feedback to Microsoft” link and let us know about the issue!  You can tell them I sent you!  It is a clear bug if that is not there.    Oh, and if you are producing a framework you should do the same!

 

Slide 11: During our API review process we absolutely focus on this by making sure that types that introduce virtual members have some concrete scenario they are supporting. I wish a had a dollar for every member we changed to non-virtual after those conversations 😉

 

Slide 15: You gotta love the “typically Microsoft thinking” quote… Remember this was for an internal audience… I suspect while you can agree with the MS issue here, you can see the same kind of “over design” issue in your own products as well.

 

Slide 16: Just for your own information, while we did have several different IO implementations before we closed on the one we shipped with in V1.0, none of them were interface based J

 

Slide 23: Has anyone run into a case where you needed to explicit implementation support a la IGraphics and IBandit

 

Designing .NET Class Libraries: Designing Inheritance Hierarchies
Learn how to design appropriately for specialization, specifically when to use inheritance over aggregation, abstract classes over interfaces, and so on. Also, learn situations in which virtual methods are called for.

[300k] [Sign up for the post session chat]

Sign up for coming chats…

2/18 – API Usability [Sign up for the post session chat]
2/25 – Designing Progressive APIs [Sign up for the post session chat]
3/9 –  CLR Performance Tips [Sign up for the post session chat]
3/16 – Designing for a Managed Memory World [Sign up for the post session chat]

 

Comments (13)

  1. RichB says:

    IGraphics – yes. I needed to export a drawing to PDF and SVG – but GDI+ does not support these types.

  2. Barry Kelly says:

    I’d love to know if any progress has been made on the front of making these presentations downloadable for offline viewing.

  3. Sean Chase says:

    It’s a breaking change to go from virtual to non-virtual…what are your thoughts as far as access modifiers on fields? I’m assuming the same – start private, promote to protected when needed. Is that a breaking change? Obviously the other way around it is. 🙂

  4. Andrew G. J. Fung says:

    Is there a centralized listing of presentations of this sort? Certainly I found all the other ones in this series, but I couldn’t find any other presentations that Microsoft does like this. I think presentations like these are an incredible find just to hear people’s experiences, opinions, and reasonings.

    Barry, there’s a tool called mmsclient you can use (linux only) to download these. You look at the source for the page, download the ASF, look in the ASF, and pass in the mms:// URL to mmsclient.

  5. G. Man says:

    Please tell me that "senior" people did not get slide 8 wrong!! EGADS!! They dont know what "virtual" means?? WTF!!!

  6. Why include a "virtual" modifier keyword at all if the implementation of that feature in the language is incomplete. Its clear that a "contract" is needed to keep the developer (who derives) in check.

    The contract is meaningless if it exists only in documentation form (ie a txt file or a web page). How about having options within the language specification that enforces a written contract. So when you mark a member as virtual you are able to set some rules within your code that enforce what needs to happen if the developer overrides the member. If the developer overrides the member but does not perform the requirements of the contract, the compiler raises exceptions to that effect.

    Also, if this feature was not present in c#, you’d get all the C++ and java big heads slagging it for not having the feature; therefore its not the new "language du jour". But its there and like other languages the implementation seems incomplete.

    What do you think about that?

  7. Brad Abrams on Designing Inheritance Hierarchies (Summary)

Skip to main content