12 Answers
12

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.

+1 for the last paragraph. I've frequently found too much encapsulation in 3rd party libraries (or even standard library classes!) to be a bigger cause of pain than too little encapsulation.
–
Mason WheelerNov 21 '12 at 15:20

@RobertHarvey I am familiar with the argument and it sounds great in theory. You as the object designer cannot forsee how people may extend your classes--that is precisely why they should not be sealed. You cannot support everything--fine. Don't. But don't take options away, either.
–
MichaelNov 21 '12 at 15:37

6

@RobertHarvey isn't that just people breaking LSP getting what they deserve?
–
StuperUserNov 21 '12 at 15:42

2

I'm not a big fan of sealed classes either, but I could see why some companies like Microsoft (who frequently have to support things that they did not break themselves) find them appealing. Users of a framework are not necessarily supposed to have knowledge of a class's internals.
–
Robert HarveyNov 21 '12 at 15:45

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.

But you can apply the same argument to classes which are not part of a public interface. One of the main reasons to make a class final is that it acts as a safety measure to prevent sloppy code. That argument is just as valid for any codebase which is shared by different developers over time, or even if you are the only developer. It just protects the semantics of the code.
–
JubbatNov 30 '12 at 16:43

I think the idea that classes should be abstract or sealed is part of a broader principle, which is that one should avoid using variables of instantiable class types. Such avoidance will make it possible to create a type which can be used by the consumers of a given type, without it having to inherit all the private members thereof. Unfortunately, such designs don't really work with public-constructor syntax. Instead, code would have to replace new List<Foo>() with something like List<Foo>.CreateMutable().
–
supercatMar 11 '14 at 21:47

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.

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.

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:

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.

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.

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>.

If I was in charge of this, I'll probably do CollectionBase(abstract), Collection : CollectionBase(sealed), ObservableCollection : CollectionBase(sealed). If you look at Collection<T> closely, you'll see it's a half-assed abstract class.
–
Nicolas RepiquetNov 21 '12 at 15:26

2

What advantage do you gain from having three classes instead of just two? Also, how is Collection<T> a "half-assed abstract class"?
–
FishBasketGordoNov 21 '12 at 15:27

Collection<T> exposes a lot of innards through protected methods and properties, and is clearly meant to be a base class for specialized collection. But it's not clear where you're supposed to put your code, as there is no abstract methods to implements. ObservableCollection inherits from Collection and is not sealed, so you can again inherit from it. And you can access the Items protected property, allowing you to add items in the collection without raising events... Nice.
–
Nicolas RepiquetNov 21 '12 at 16:34

@NicolasRepiquet: In many languages and frameworks, the normal idiomatic means of creating an object requires that the type of the variable which will hold the object be the same as the type of the created instance. In many cases, the ideal usage would be to pass around references to an abstract type, but that would force a lot of code to use one type for variables and parameters and a different concrete type when calling constructors. Hardly impossible, but a bit awkward.
–
supercatNov 21 '12 at 21:10

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.

Final-sealed stuff in software solves the problem of "I feel the need to impose my will on future maintainers of this code".
–
KazNov 21 '12 at 23:39

Wasn't final/seal something added to OOP, because I don't remember it being around when I was younger. It seems like an after thought kind of feature.
–
ThinkingMediaNov 22 '12 at 16:50

Finalizing existed as a toolchain procedure in OOP systems before OOP became dumbed down with languages like C++ and Java. Programmers work away in Smalltalk, Lisp with maximum flexibility: anything can be extended, new methods added all the time. Then, the compiled image of the system is subject to an optimization: an assumption is made that the system won't be extended by the end users, and so this means that the method dispatch can be optimized based on taking stock of what methods and classes exist now.
–
KazNov 22 '12 at 16:55

I don't think that's the same thing, because this is just an optimization feature. I don't remember sealed being in all versions of Java, but I could be wrong as I don't use it much.
–
ThinkingMediaNov 22 '12 at 16:58

Just because it manifests itself as some declarations that you have to put into the code doesn't mean it isn't the same thing.
–
KazNov 22 '12 at 17:21

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 (tm). 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.

"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.

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.