C# 4 and .NET 4

94 ❘ ChaPTer 4 inheritAnce
sealed Classes and methods
C# allows classes and methods to be declared as sealed. In the case of a class, this means that you can’t
inherit from that class. In the case of a method, this means that you can’t override that method.
sealed class FinalClass
{
// etc
}
class DerivedClass: FinalClass
{
// etc
}
// wrong. Will give compilation error
The most likely situation in which you’ll mark a class or method as sealed is if the class or method is
internal to the operation of the library, class, or other classes that you are writing, so that you ensure that
any attempt to override some of its functionality will lead to instability in the code. You might also mark a
class or method as sealed for commercial reasons, in order to prevent a third party from extending your
classes in a manner that is contrary to the licensing agreements. In general, however, you should be careful
about marking a class or member as sealed because by doing so you are severely restricting how it can be
used. Even if you don’t think it would be useful to inherit from a class or override a particular member of it,
it’s still possible that at some point in the future someone will encounter a situation you hadn’t anticipated
in which it is useful to do so. The .NET base class library frequently uses sealed classes to make these
classes inaccessible to third-party developers who might want to derive their own classes from them. For
example, string is a sealed class.
Declaring a method as sealed serves a similar purpose as for a class:
class MyClass: MyClassBase
{
public sealed override void FinalMethod()
{
// etc.
}
}
class DerivedClass: MyClass
{
public override void FinalMethod() // wrong. Will give compilation error
{
}
}
In order to use the sealed keyword on a method or property, it must have first been overridden from a base
class. If you do not want a method or property in a base class overridden, then don’t mark it as virtual.
Constructors of derived Classes
Chapter 3 discusses how constructors can be applied to individual classes. An interesting question arises
as to what happens when you start defining your own constructors for classes that are part of a hierarchy,
inherited from other classes that may also have custom constructors.
Assume that you have not defined any explicit constructors for any of your classes. This means that the
compiler supplies default zeroing-out constructors for all your classes. There is actually quite a lot going
on under the hood when that happens, but the compiler is able to arrange it so that things work out nicely
throughout the class hierarchy and every field in every class gets initialized to whatever its default value is.
When you add a constructor of your own, however, you are effectively taking control of construction. This
has implications right down through the hierarchy of derived classes, and you have to make sure that you
don’t inadvertently do anything to prevent construction through the hierarchy from taking place smoothly.
www.it-ebooks.info