Learn how to design appropriately for specialization, specifically when to use inheritence over aggregation, abstract classes over interfaces, and so on. Also, learn situations in which virtual methods are called for. Notes from CLR Lead Program Manager Brad Abrams... 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 one 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 "typical 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 :-) Slide 23: Has anyone run into a case where you needed to explicit implementation support a la IGraphics and IBandit |
.jpg)