Ironically, I find the opposite: the use of abstract classes is the exception rather than the rule and I tend to frown on final/sealed classes.

Interfaces are a more typical design-by-contract mechanism because you do not specify any internals–you are not worried about them. It allows every implementation of that contract to be independent. This is key in many domains. For example, if you were building an ORM it would be very important that you can pass a query to the database in a uniform way, but the implementations can be quite different. If you use abstract classes for this purpose, you end up hard-wiring in components that may or may not apply to all implementations.

For final/sealed classes, the only excuse I can ever see for using them is when it is actually dangerous to allow overriding–maybe an encryption algorithm or something. Other than that, you never know when you may wish to extend the functionality for local reasons. Sealing a class restricts your options for gains that are non-existent in most scenarios. It is far more flexible to write your classes in a way that they can be extended later down the line.

This latter view has been cemented for me by working with 3rd party components that sealed classes thereby preventing some integration that would have made life a lot easier.

That is a great article by Eric Lippert, but I don’t think it supports your viewpoint.

He argues that all classes exposed for use by others should be sealed, or otherwise made non-extensible.

Your premise is that all classes should be abstract or sealed.

Big difference.

EL’s article says nothing about the (presumably many) classes produced by his team that you and I know nothing about. In general the publicly-exposed classes in a framework are only a subset of all the classes involved in implementing that framework.

From a java perspective I think that final classes are not as smart as it seems.

Many tools (especially AOP, JPA etc) work with load time waeving so they have to extend your clases. The other way would be to create delegates (not the .NET ones) ad delegate everything to the original class which would be much more messy than extending the users classes.

Two common cases where you will need vanilla, non-sealed classes:

1. Technical: If you have a hierarchy that is more than two levels deep, and you want to be able to instantiate something in the middle.

2. Principle: It is sometimes desirable to write classes that are explicity designed to be safely extended. (This happens a lot when you are writing an API like Eric Lippert, or when you’re working in a team on a large project). Sometimes you want to write a class that works fine on its own, but it is designed with extensibility in mind.

Eric Lippert’s thoughts on sealing makes sense, but he also admits that they do design for extensibility by leaving the class “open”.

Yes, many classes are sealed in the BCL, but a huge number of classes are not, and can be extended in all sorts of wonderful ways. One example that comes to mind is in Windows Forms, where you can add data or behavior to almost any Control via inheritance. Sure, this could have been done in other ways (decorator pattern, various types of composition, etc.), but inheritance works very well, too.

Two .NET specific notes:

1. In most circumstances, sealing classes often not critical for safety, because inheritors cannot mess with your non-virtual functionality, with the exception of explicit interface implementations.
2. Sometimes a suitable alternative is to make the Constructor internal instead of sealing the class, which allows it to be inherited inside your codebase, but not outside of it.

I believe the real reason many people feel classes should be final/sealed is that most non-abstract extendable classes are not properly documented.

Let me elaborate. Starting from afar, there is the view among some programmers that inheritance as a tool in OOP is widely overused and abused. We’ve all read the Liskov substitution principle, though this didn’t stop us from violating it hundreds (maybe even thousands) of times.

The thing is programmers love to reuse code. Even when it’s not such a good idea. And inheritance is a key tool in this “reabusing” of code. Back to the final/sealed question.

The proper documentation for a final/sealed class is relatively small: you describe what each method does, what are the arguments, the return value, etc. All the usual stuff.

However, when you are properly documenting an extendable class you must include at least the following:

• Dependencies between methods (which method calls which, etc.)
• Dependencies on local variables
• Internal contracts that the extending class should honor
• Call convention for each method (e.g. When you override it, do you call the super implementation? Do you call it in the beginning of the method, or in the end? Think constructor vs destructor)
• …

These are just off the top of my head. And I can provide you with an example of why each of these is important and skipping it will screw up an extending class.

Now, consider how much documentation effort should go into properly documenting each of these things. I believe a class with 7-8 methods (which might be too much in an idealized world, but is too little in the real) might as well have a documentation about 5 pages, text-only. So, instead, we duck out halfway and don’t seal the class, so that other people can use it, but don’t document it properly either, since it will take a giant amount of time (and, you know, it might never be extended anyway, so why bother?).

If you’re designing a class, you might feel the temptation to seal it so that people cannot use it in a way you’ve not foreseen (and prepared for). On the other hand when you’re using someone else’s code, sometimes from the public API there is no visible reason for the class to be final, and you might think “Damn, this just cost me 30 minutes in search for a workaround”.

I think some of the elements of a solution are:

• First to make sure extending is a good idea when you’re a client of the code, and to really favor composition over inheritance.
• Second to read the manual in its entirety (again as a client) to make sure you’re not overlooking something that is mentioned.
• Third, when you are writing a piece of code the client will use, write proper documentation for the code (yes, the long way). As a positive example, I can give Apple’s iOS docs. They’re not sufficient for the user to always properly extend their classes, but they at least include some info on inheritance. Which is more than I can say for most APIs.
• Fourth, actually try to extend your own class, to make sure it works. I am a big supporter of including many samples and tests in APIs, and when you’re making a test, you might as well test inheritance chains: they are a part of your contract after all!
• Fifth, in situations when you’re in doubt, indicate that the class is not meant to be extended and that doing it is a bad idea ™. Indicate you should not be held accountable for such unintended use, but still don’t seal the class. Obviously, this doesn’t cover cases when the class should be 100% sealed.
• Finally, when sealing a class, provide an interface as an intermediate hook, so that the client can “rewrite” his own modified version of the class and work around your ‘sealed’ class. This way, he can replace the sealed class with his implementation. Now, this should be obvious, since it is loose coupling in its simplest form, but it’s still worth a mention.

It is also worth to mention the following “philosophical” question: Is whether a class is sealed/final part of the contract for the class, or an implementation detail? Now I don’t want to tread there, but an answer to this should also influence your decision whether to seal a class or not.

A class should neither be final/sealed nor abstract if:

• It’s useful on its own, i.e. it’s beneficial to have instances of that class.
• It’s beneficial for that class to be the subclass/base class of other classes.

For example, take the ObservableCollection<T> class in C#. It only needs to add the raising of events to the normal operations of a Collection<T>, which is why it subclasses Collection<T>. Collection<T> is a viable class on its own, and so it ObservableCollection<T>.

I agree with your view. I think that in Java, by default, classes should be declared “final”. If you don’t make it final, then specifically prepare it and document it for extension.

The main reason for this is to ensure that any instances of your classes will abide to the interface you originally designed and documented. Otherwise a developer using your classes can potentially create brittle and inconsistent code and, on its turn, pass that on to other developers / projects, making objects of your classes not trustable.

From a more practical perspective there is indeed a downside to this, since clients of your library’s interface won’t be able to do any tweaking and use your classes in more flexible ways that you originally thought of.

Personally, for all the bad quality code that exists (and since we are discussing this on a more practical level, I would argue Java development is more prone to this) I think this rigidity is a small price to pay in our quest for easier to maintain code.

The problem with final/sealed classes is that they are trying to solve a problem that hasn’t happen yet. It’s useful only when the problem exists, but it’s frustrating because a third-party has imposed a restriction. Rarely does sealing class solve a current problem, which makes it difficult to argue it’s usefulness.

There are cases where a class should be sealed. As example; The class manages allocated resources/memory in a way that it can not predict how future changes might alter that management.

Over the years I’ve found encapsulation, callbacks and events to be far more flexible/useful then abstracted classes. I see far to much code with a large hierarchy of classes where encapsulation and events would have made life simpler for the developer.

“Sealing” or “finalizing” in object systems allows for certain optimizations, because the complete dispatch graph is known.

That is to say, we make it difficult for the system to be changed into something else, as a trade-off for performance. (That is the essence of most optimization.)

In all other respects, it’s a loss. Systems should be open and extensible by default. It should be easy to add new methods to all classes, and extend arbitrarily.

We don’t gain any new functionality today by taking steps to prevent future extension.

So if we do it for the sake of prevention itself, then what we are doing is trying to control the lives of future maintainers. It is about ego. “Even when I no longer work here, this code will be maintained my way, damn it!”

Test classes seem to come to mind. These are classes that are called in an automated fashion or “at will” based on what the programmer/tester is trying to accomplish. I’m not sure I’ve ever seen or heard of a finished class of tests that’s private.

The time when you need to consider a class that is intended to be extended is when you are doing some real planning for the future. Let me give you a real life example from my work.

I spend a good deal of my time writing interface tools between our main product and external systems. When we make a new sale, one big component is a set of exporters that are designed to be run at regular intervals which generate data files detailing the events that have happened that day. These data files are then consumed by the customer’s system.

This is an excellent opportunity for extending classes.

I have an Export class which is the base class of every exporter. It knows how to connect to the database, find out where it had got to last time it ran and create archives of the data files it generates. It also provides property file management, logging and some simple exception handling.

On top of this I have a different exporter to work with each type of data, perhaps there is user activity, transactional data, cash management data etc.

On top of this stack I place a customer-specific layer which implements the data file structure the customer needs.

In this way, the base exporter very rarely changes. The core data-type exporters sometimes change but rarely, and usually only to handle database schema changes which should be propagated to all customers anyway. The only work I ever have to do for each customer is that part of the code that is specific to that customer. A perfect world!

So the structure looks like:

Base
 Function1
  Customer1
  Customer2
 Function2
 ...

My primary point is that by architecting the code this way I can make use of inheritance primarily for code re-use.

I have to say I cannot think of any reason to go past three layers.

I have used two layers many times, for example to have a common Table class which implements database table queries while sub-classes of Table implement the specific details of each table by using an enum to define the fields. Letting the enum implement an interface defined in the Table class makes all sorts of sense.

I have found abstract classes useful but not always needed, and sealed classes become an issue when applying unit tests. You can’t mock or stub a sealed class, unless you use something like Teleriks justmock.

As an example, NSView / UIView in MacOS / iOS is very useful on its own, without any modifications, but there are also many useful subclasses, and you will most likely create your own useful subclasses. It’s not abstract, and it can’t be final. And it’s one of the most used classes because without it you can’t draw anything on the screen.