File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes MyGUI extends JFrame - good or bad? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "MyGUI extends JFrame - good or bad?" Watch "MyGUI extends JFrame - good or bad?" New topic
Author

MyGUI extends JFrame - good or bad?

Charlie Goth
Ranch Hand

Joined: Feb 26, 2004
Posts: 60
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?


SCJP (77%)
Xie Ruchang
Ranch Hand

Joined: Dec 25, 2003
Posts: 160
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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).


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Dec 25, 2003
Posts: 160
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
Ranch Hand

Joined: May 29, 2003
Posts: 1258
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.


Nathaniel Stodard<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS, ICAD, ICSD, ICED
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Dec 25, 2003
Posts: 160

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
Ranch Hand

Joined: Dec 25, 2003
Posts: 160

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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Dec 25, 2003
Posts: 160

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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: MyGUI extends JFrame - good or bad?