DotNet - bad for your skills...
Apparently, DotNet actively rots your brain - just look at this post:
I'm sitting here at work building an application using TDD (which by itself is another post, and may be coming later), and every time I start a new class for another piece of the puzzle, I'm hating on how I have put the keyword "sealed" class in my declaration. Now, this isn't a major issue, but it can be if you plan on releasing an API for customers to build against. What's my issue? Well, I'm wondering if the "sealed" and "notinheritable" keywords should be applied by default in Whidbey.
He calls this "good design". Uh huh. Assuming that you know everything and that the end users of your code know nothing, I suppose it is. If you assume some level of intelligence in the end users of your code, it's just bad. I'm starting to think that "sealed" and "final" do more harm than static typing - they encourage closed end systems that cannot be extended without heroic efforts on the part of end developers. Run, don't walk, from any code developed by people who think this way...
Comments
Untitled
[anthony] April 16, 2004 10:16:24.021
Especially true since the most likely end user of your code...is you!
Untitled
[Gordon Weakliem] April 16, 2004 14:31:36.225
Eric Lippert had a few posts on this a while back (he advocates sealed) and I argued with him, but he convinced me for his case. On top of that, there's a few problems with the .NET type system itself that makes subclassing unsafe in some edge cases. I'd point you at a few of my posts on the subject, but the machine that hosts my domain died an awful death earlier this week and isn't back up yet.
Untitled
[Adam V.] April 16, 2004 14:49:41.886
Gordon: this one? http://weblogs.asp.net/ericlippert/archive/2004/01/22/61803.aspx
Designing to be inherited is extra effort
[Shane King] April 16, 2004 20:26:54.253
It's extra effort, since you have to think about not only what public interface to provide to users of the class, but also what interface to provide for people who want to inherit your class. Often it's just not worth putting in that effort. Marking your class as sealed is a way of saying "I didn't have the time or inclination to ensure that you can inherit this in a reasonable fashion, so I'm not going to let you do it at all". It's not telling your users what they should and shouldn't do as such, it's admitting you don't know enough to allow them to inherit, and so not letting them do so. Which is IMO a better decision than letting them do it anyway, and then getting stung when you have to change the class in a way that breaks the classes that inherit from you.
Untitled
[Hmmm...] April 16, 2004 20:49:45.161
Ah... if you provided all your source code you could have your clients inherit if they want because they would be able to do what they need - as opposed to final, sealed, etc... blergh. Just consequences of bad tools.
Re: DotNet - bad for your skills...
[James Robertson] April 16, 2004 22:18:35.454
Comment on DotNet - bad for your skills... by James Robertson
So rather than empower people, MS tools remove power and call it "good". I know that smell...
Re: DotNet - bad for your skills...
[Christopher Caserio] April 17, 2004 15:01:33.052
Comment on DotNet - bad for your skills... by Christopher Caserio
The real problem is implementation inheritance itself. See Alan Snyder's OOPSLA '86 paper ("Encapsulation and Inheritance in Object-Oriented Languages") for details. An excerpt from the abstract is included here:
A subsequent paper from OOPSLA '87 by Lynn Andrea Stein, "Delegation IS Inheritance", provides a formal analysis of the characteristics of the two sharing mechanisms, to show that they are equivalent.