Mike Most of your points I think are covered by my reply to Ian. But one other point. You say:
> Furthermore, in the absence of planned polymorphism via overridable methods > in the base class, the derive type developer's reuse model is reduced to > delegation; by providing new methods on the derived type that "call up" to > the base type to accomplish work. You don't need inheritance to accomplish > that. A private member variable that refers to the type being reused will > accomplish just as much with the same amount of code. I don't believe that's true. Deriving from the class mean your class exposes all the base class's public members for free. A private member variable means you have to explicitly provide wrapper methods for each one. And if the base class contains a lot of methods that could be a lot of work. Simon ----------------------------------------------------------- Simon Robinson http://www.SimonRobinson.com ----------------------------------------------------------- ----- Original Message ----- From: "Mike Woodring" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 03, 2002 5:04 PM Subject: Re: [ADVANCED-DOTNET] sealed: why? > For the record, I side with Ian & Craig. Now onto a specific reply > (below)... > > From: "Simon Robinson" <[EMAIL PROTECTED]> > > > > I'd have said that even if you feel your class is imperfect, then by > > not having it as sealed you give other developers the freedom to > > derive from it and save themselves effort duplicating your code > > if they wish to. > > But deriving from someone else's class is not the only way to reuse that > class. It's that inclination to reuse-by-inheritance that I think helps > make a mess of things. If a class designer hasn't put any thought into what > it means for someone to build a derived class, then it's unlikely that > anyone subsequently creating a derived class will achieve the productivity > gains that they believe they're going to reap. For example, it's unlikely > that the base class designer made all of their interesting methods virtual. > And if the methods aren't virtual, then it means that the base class wasn't > designed and used throughout the code in a way that can leverage > polymorphism. In other words, if the original base class is being used > through the codebase in a certain way, then simply defining a new derived > type an "plugging it in" to the existing code isn't going to work in terms > of the existing code now suddenly taking advantage of the derived type's > functionality. > > So what "reuse" was achieved by the derived class developer? They have a > class which is type compatible with the base class, but that can't be > substituted polymorphically anywhere. Instead, they have to do one of the > following: > > (a) change existing references to the base type to refer to the derived type > so that the derived type's methods can be called; > > (b) use downcasting everywhere that the functionality of the derived type > needs to be called, but where base type reference is at hand. > > Both of which are indicators that you're trying to fit a square peg in a > round whole. > > Furthermore, in the absence of planned polymorphism via overridable methods > in the base class, the derive type developer's reuse model is reduced to > delegation; by providing new methods on the derived type that "call up" to > the base type to accomplish work. You don't need inheritance to accomplish > that. A private member variable that refers to the type being reused will > accomplish just as much with the same amount of code. > > So if you haven't designed your class to support polymorphic usage via > overridable methods, then allowing someone to derive from it is *not* likely > to yield any real benefits to the client developer or derived class > developer, but *is* likely to perpetuate the misuse of the type (IMO, > obviously :-) Any benefits that do happen to be gained as a result of being > able to derive from a class that wasn't designed/implemented with > inheritance in mind are really accidental and not necessarily justifications > for inheritable-by-default. > > -Mike > http://staff.develop.com/woodring > http://www.develop.com/devresources > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
