MyGUI extends JFrame - good or bad?

[Charlie Goth]

I've always understood it that you should only extend a class if you want a new and improved version, not because you want the functionality.
But every gui example I see extends JFrame, is this good or bad? Surely they could get the functionality by having a 'has-a' relationship rather than 'is-a'. I asked a tutor about this a while ago and he said extending JFrame was fine (He said extending Thread is fine too, so what does he know?) but I'm still not sure. Extending JFrame will expose so much functionality to outside the gui, when really it should be kept hidden.
Any thoughts?

[Xie Ruchang]

Hi,
I read from Peter Coad book Java Design that we should favour Object Composition rather than Object Inheritance. There are reasons for extending a class which I won't talk about here.
Basically, if you have an application which uses JFrame, I would use Object Composition. As Java supports only single inheritance, my application that using JFrame can be extended further by inheritance. If the application extends JFrame, you left with no choice.
Best Regards
PS:
The question to ask "Is my application really is-a JFrame".
Yes --> use inheritance
No --> that is my application just use a JFrame, use object composition.

[Ilja Preuss]

Originally posted by Frankie Cha:
The question to ask "Is my application really is-a JFrame".
Yes --> use inheritance
No --> that is my application just use a JFrame, use object composition.

That's only a very rough heuristic, and often enough it fails. For example, a square certainly "is a" rectangle, but in some situations letting square extend rectangle can bring you in real trouble (as it might violate Liskov's Substitution Principle).

[Ilja Preuss]

Originally posted by Charlie Goth:
Extending JFrame will expose so much functionality to outside the gui, when really it should be kept hidden.

Extending JFrame isn't bad, if what you do is basically writing an extended version of a JFrame (for exmaple, if it fills itself with some widgets and calculates its position on the screen).
What I wouldn't do is putting non-gui logic into a class that inherits from a gui class. It violates the Single Responsibility Principle and couples your gui logic to you business logic (for example), making it thereby harder to vary one without affecting the other.

[Xie Ruchang]

Hi Ilja

Extending JFrame isn't bad, if what you do is basically writing an extended version of a JFrame (for exmaple, if it fills itself with some widgets and calculates its position on the screen).

Bearing in mind, the same can be done with object composition, I will not using inheritance because it is very clear to the next person maintaining the code that I am not changing any behaviour of JFrame. This is the JavaBean approach to component building.
Unless, I am changing the some behaviour of JFrame like over-riding the paint event, I will not use inheritance for this reason. Inheritance coupling add more complexity than mere class association. As such, if both can be done by inheritance and composition. Object composition is the better approach! You mentioned LSP. The whole idea of LSP is to minimise inheritance coupling. Thus in a sense LSP favours object composition rather than inheritance. Why break encapsulation by inheritance when no purpose is achieved?
[ March 09, 2004: Message edited by: Frankie Cha ]

[Nathaniel Stoddard]

I think the argument comes into the foreground when the child class is not really an instance of the base class -- the classic example being implementing a Stack using a List. A Stack is-not a List. (Actually, I don't think that's the classic example, which I suddenly can't remember -- perhaps it's not so classic after all).
In our JFrame example, extending it will indeed make another JFrame complete with the Is-A relationship intact. I think it's appropriate to increase the readability of the application, too, and this would certainly do that -- without having to dispatch all the unrelevant calls to the contained class, if it was implemented as such.

[Ilja Preuss]

Originally posted by Nathaniel Stoddard:
(Actually, I don't think that's the classic example, which I suddenly can't remember -- perhaps it's not so classic after all).

As far as I know, the classic example is the square vs. rectangle (respectively circle vs. ellipse) problem. In mathematics, a square is-a rectangle. In software development, a Square type might not be a subtype of a Rectangle type. That is, you possibly can't use a Square instance everywhere you can use a Rectangle instance.

[Ilja Preuss]

Originally posted by Frankie Cha:
Inheritance coupling add more complexity than mere class association.

I actually think that typically the reverse is true.
Think about the design patterns Template Method and Strategy as an example. Both basically do the same thing, the former using inheritance, the latter using composition.
Strategy is more complex, though - you need an additional interface, the clients of the strategy need to somehow get configured with the correct strategy instance etc. Those costs are justified if you can make use of the increased flexibility (being able to reconfigure the strategy at runtime) and reusability (using strategy instances with more than one client). Otherwise the simpler Template Method approach is more appropriate.

You mentioned LSP. The whole idea of LSP is to minimise inheritance coupling.

Is it? To me the whole idea of the LSP is substitutability - clients of a class hierarchy shouldn't care which derivative of a superclass/interface they are working on. I don't see in which way this favors composition over inheritance...
[ March 10, 2004: Message edited by: Ilja Preuss ]

[Xie Ruchang]

Is it? To me the whole idea of the LSP is substitutability - clients of a class hierarchy shouldn't care which derivative of a superclass/interface they are working on. I don't see in which way this favors composition over inheritance...

Of course the whole idea of LSP is substitutability, otherwise it should not be called Liskov Substitution Principle. This principle given by Barbara Liskov basically states that derived classes should be substitutable for their base class. If this principle is adhered to, you will find a lot of inheritance hierarchies gone, done away with in JDK. It is basically trying to discourage the use of inheritance. Since, reusability is achieved through either inheritance or composition, LSP favours composition in this sense.
Case A : MyJFrame extends JFrame and adds several widgets into it.
Case B : MyAppl uses JFrame and adds several different widgets into it.
Can MyJFrame in Case A substitutes JFrame in Case B. I think no. Thus LSP is violated. Object composition should be used instead if you are a pure LSP adherent.
I am not saying we should not be inheriting JFrame, for convenience, I do extend JFrame because calling JFrame methods is easier than by object composition which need a reference of a JFrame.

[Xie Ruchang]

I actually think that typically the reverse is true.
Think about the design patterns Template Method and Strategy as an example. Both basically do the same thing, the former using inheritance, the latter using composition.
Strategy is more complex, though - you need an additional interface, the clients of the strategy need to somehow get configured with the correct strategy instance etc. Those costs are justified if you can make use of the increased flexibility (being able to reconfigure the strategy at runtime) and reusability (using strategy instances with more than one client). Otherwise the simpler Template Method approach is more appropriate.

One additional interface doesn't make it more complex as compare to layers and layers of inheritance hierarchies! (C++ multiple inheritance) On the contrary the interface simplifies it so that the users need not goes through the inheritance hierachy. The interface states clearly what are the methods that are exposed. There is no breaking of encapsulation by inheritance and the user need not to look at the inherited methods which are not of concern to him.
[ March 10, 2004: Message edited by: Frankie Cha ]

[Ilja Preuss]

Originally posted by Frankie Cha:
If this principle is adhered to, you will find a lot of inheritance hierarchies gone, done away with in JDK.

I am only aware of very few LSP violations in the JDK (e.g. java.sql.Date, if I remember correctly). What hierarchies are you thinking of?

Case A : MyJFrame extends JFrame and adds several widgets into it.
Case B : MyAppl uses JFrame and adds several different widgets into it.
Can MyJFrame in Case A substitutes JFrame in Case B. I think no.

Why not???

[Xie Ruchang]

I am only aware of very few LSP violations in the JDK (e.g. java.sql.Date, if I remember correctly). What hierarchies are you thinking of?

Do you think the java.awt.Container, java.awt.Component and javax.swing.JComponent classes violate the LSP?
[ March 10, 2004: Message edited by: Frankie Cha ]

[Ilja Preuss]

Originally posted by Frankie Cha:

Do you think the java.awt.Container, java.awt.Component and javax.swing.JComponent classes violate the LSP?

Ah, yes, of course.
I am not sure that using Composition would have reduced complexity, though. Might be one of those cases were multiple inheritance would have been valuable...