Why is subclassing not allowed for many of the SWT Controls?

Question

I often find myself wanting to do it. It can be very useful when you want to store some useful information or extra states.

So my question is, is there a very good/strong reason why this is forbidden?

Thanks

EDIT: Thanks a lot for all these answers. So it sounds like there's no right-or-wrong answer to this.

Assuming I accept the fact that these classes are not to be subclassed, what's the point of not marking a Control class final, but prohibiting subclassing - effectively demoting the exception/error from compile-time to run-time?

EDIT^2: See my own answer to this: apparently, these classes are overrideable, but requires explicit acknowledgement by the overrider.

Thanks

Rhoads

Answer 1

It doesn't look like anybody mentioned this in any of the answers, but SWT does provide an overrideable checkSubclass() method; precisely where the Unextendable exception is thrown. Override the method to a no-op and effectively make extending legal. I guess to leave this option open is ultimately the reason that the class is not made final and the extension error not made compile-time instead of run-time.

Example:

@Override
protected void checkSubclass() {
    //  allow subclass
    System.out.println("info   : checking menu subclass");
}

Rhoads

Good point about leaving the option open for later allowing sub-classing; although, I'd expect that the method attempts to make sure you know what you're doing. – Flyblow

Answer 2

Designing components for inheritance is hard, and can limit future implementation changes (certainly if you leave some methods overridable, and call them from other methods). Prohibiting subclassing restricts users, but means it's easier to write robust code.

This follows Josh Bloch's suggestion of "design for inheritance or prohibit it". This is a bit of a religious topic in the dev community - I agree with the sentiment, but others prefer everything to be as open to extension as possible.

Nitrobacteria

But Eclipse itself creates our Shell classes in this way (inheriting from Shell) and then overriding checkSubclass() with empty body. So is it good(safe) that we do this way? I have two shells (Shell_1, Shell_2). Shell_1 is parent of Shell_2. I only want to extend from Shell class for Shell_2 so I can simply add controls on it inside the constructor of Shell_2. Is this wrong way to do? – Izy

@MajidAzimi: I don't know what the Shell class is, or the details of it - but in general I'd try to avoid over-using inheritance. – Nitrobacteria

Answer 3

It is very hard to create class that can be safely subclassed. You have to think about endless use cases and protect you class very well. I believe that this is a general reason to mark API class as final.

Numen

Answer 4

As for your follow-up question:

what's the point of not marking a Control class final, but prohibiting subclassing - effectively demoting the exception/error from compile-time to run-time?

It's not possible for SWT to subclass the Control class, if they mark it final. But they have to internally. So they defer the checking to runtime.

BTW, if you want an insane hack, you can still subclass Control or any other SWT class, by putting your subclass into the org.eclipse.swt.widgets package. But I never really had to do that.

Buiron

Answer 5

The method description of org.eclipse.swt.widgets.Widget.checkSubclass() says:

Checks that this class can be subclassed.

The SWT class library is intended to be subclassed only at specific, controlled points (most notably, Composite and Canvas when implementing new widgets). This method enforces this rule unless it is overridden.

IMPORTANT: By providing an implementation of this method that allows a subclass of a class which does not normally allow subclassing to be created, the implementer agrees to be fully responsible for the fact that any such subclass will likely fail between SWT releases and will be strongly platform specific. No support is provided for user-written classes which are implemented in this fashion.

The ability to subclass outside of the allowed SWT classes is intended purely to enable those not on the SWT development team to implement patches in order to get around specific limitations in advance of when those limitations can be addressed by the team. Subclassing should not be attempted without an intimate and detailed understanding of the hierarchy.

Throws: SWTException
ERROR_INVALID_SUBCLASS - if this class is not an allowed subclass

Roorback