• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

Design advice

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone!
This is my first post here!
I like Java, I also worked as a Java developer(10 months), but know, I want to get better and I need your advice. Thank you!

I have two panels, each with his class(trying to make as loosely coupled as I can) and a frame that has a panel with CardLayout so I can switch between panels.



So, what will be a better solution not to use JPanel general as static?

Thank you!
 
Saloon Keeper
Posts: 11906
253
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Vlad, welcome to CodeRanch!

A better solution is to make the frame responsible for switching panels. The first panel is constructed with a callback, and executes that callback whenever it has done doing what it's supposed to do. The frame passes a callback in which it switches the panel.

A few other points:
- Don't make big listeners that handle multiple controls. Make a listener per control. In Java 8, you can easily do this with method references.
- Keep strong references. If you have to cast the frame's layout, just keep a strong reference in a separate field.
- As you've already identified: Never use mutable static fields! The static general panel is a NO NO.
- Don't do things in constructors. Constructors are only for initialization. The setVisible() method will start up the event dispatch thread, which is a bad idea to do from a constructor.
- Finish laying out your components before you make things visible. setVisible() should be the last call.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see a bug in your code:

This should have been:

You don't want to compare whatever e.getSource() returns to the string "jbtOk", you want to check if it is the object that the variable jbtOk refers to.
 
Vlad Adrian
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much, Stephan van Hulst, for the solution and for the advices. I will modify the code according to your advices and post it again.
 
Vlad Adrian
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jesper de Jong wrote:I see a bug in your code:

This should have been:

You don't want to compare whatever e.getSource() returns to the string "jbtOk", you want to check if it is the object that the variable jbtOk refers to.



Hello,

Yes, I know, I wrote it in a hurry, I know it should not be a String. Thank you for pointing it out!
 
Stephan van Hulst
Saloon Keeper
Posts: 11906
253
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, Actions are awesome. Define actions on your components, and you can use them as different controls!

 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jesper de Jong wrote:This should have been:


Not
  if ( e.getSource().equals(jbtOk) ) { ...
?

Just asking (I'm no Swing expert) because it goes against our usual advice to AvoidTheEqualityOperator (←click).

Winston
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Winston You could argue that in this case you would want to check that the event came from the actual JButton object that you've created and that's used in the GUI, so reference equality is what you'd want to use.

(In practice it doesn't matter since JButton inherits its equals() method from Object, which does the same as ==).
 
Stephan van Hulst
Saloon Keeper
Posts: 11906
253
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the point is moot anyway, because the handler should never care where the event came from.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jesper de Jong wrote:@Winston You could argue that in this case you would want to check that the event came from the actual JButton object that you've created and that's used in the GUI, so reference equality is what you'd want to use...


Yeah, I thought it was probably something like that. Just needed clarification from a "hexpert".

Winston
 
Sheriff
Posts: 15527
263
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vlad Adrian wrote:trying to make as loosely coupled as I can


Referencing PANEL_TWO this way makes the Panel1 class tightly coupled with the PanelFrame class. One way you can loosen up the coupling is by injecting the reference into the Panel1 instance via a setter. See the Law of Demeter.

Stephan van Hulst wrote:


Note that calling a non-final method from a constructor can lead to unpleasant surprises in subclasses. In this case, the method called from the constructor is private so I don't think there will be a problem. See articles about calling non-final methods from constructors in Java if you want to know more.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:See the Law of Demeter...


A propos of nothing in particular: Every time I read that Law, I'm reminded of its similarity to Internet routing design - paradoxically, the less a router knows about anything except its immediate neighbours (or addresses that it's specifically responsible for) the faster throughput is in general. I forget what the theory is called.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 11906
253
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Note that calling a non-final method from a constructor can lead to unpleasant surprises in subclasses. In this case, the method called from the constructor is private so I don't think there will be a problem. See articles about calling non-final methods from constructors in Java if you want to know more.



Yes, that's why I didn't call a non-final method. Note that my class is final ;)
 
Vlad Adrian
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, I want to apologize for the late response. Second, thank you all for the help.

@Stephan van Hulst: I know it's not exactly a callback. I'll try to implement the Observer Pattern. But first I must figure out how exactly in this case.
I don't quite get it how can I store a weak reference(CardLayout c = (CardLayout) jpnl.getLayout();) into a strong one as you mentioned in the second point.

I implemented one action with lambda and one with anonymous class. I will read about method references. I didn't knew about this feature.




Thank you!

BR,
Vlad
 
Self destruct mode activated. Instructions for deactivation encoded in this tiny ad.
Two software engineers solve most of the world's problems in one K&R sized book
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic