Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Fensterklasse, Wie auf Frame im Listender zugreifen (ItemEvents)
Hi, also ich habe folgendes Problem, ich wollte bisschen mit Fensterklassen rumspielen und habe mal versucht ein Programm zu schreiben , welches ein Fenster erzeugt mit einer ClickBox. Wenn man das Häckchen setzt sollte sich die Hintergrundfarbe ändern. Nun versuche ich dies zu erreichen in dem ich in meinem Listener auf die Hintergrundfarbe meines Frames zurückgreife , aber irgendwie bekomm ich dies nicht so richtig hin
ich habe mehrer Klassen geschrieben um es ein bisschen zu üben und eine bessere Übersicht zu bekommen.
Java:
public class ActionEvent extends JFrame {
public ActionEvent(){
super ("ClickFrame");
JPanel southPanel = new JPanel();
CheckBox checkbox = new CheckBox();
southPanel.add(new JLabel("switch"));
southPanel.add(checkbox);
this.add(southPanel);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
pack();
setVisible(true);
}
public static void main(String[] args) {
new ActionEvent();
}
}
Meine CheckBox:
Code:
public class CheckBox extends JCheckBox {
public CheckBox(){
this.addItemListener(new CheckBoxListener(this));
}
mein Listener:
Code:
public class CheckBoxListener implements ItemListener {
CheckBox j;
public CheckBoxListener(CheckBox j){
this.j = j;
}
public void itemStateChanged(ItemEvent e){
Color color;
if(e.getStateChange() == ItemEvent.SELECTED){
color = Color.RED;
//wie greife ich hier auf die hintergrundfarbe zurück?
}else{
color = Color.GREEN;
//wie greife ich hier auf die hintergrundfarbe zurück?(
}
}
Dis Strukturierung ist erst einmal wenig optimal und erschwert daher den Zugriff auf die jeweiligen Elemente.
Es gibt bei sowas generell zwei Wege:
1. Möglichkeit: Das, worauf du zugreifen willst, musst Du übergeben. Also wenn Du in der Instanz von CheckBoxListener auf etwas zugreifen willst, dann musst Du es dem geben. Da es aus dem Frame kommt, musst Du das entsprechende Element halt erst an die Checkbox übergeben und von dort halt dann weiter an den Listener.
2. Möglichkeit: Die Aktion musst du auslagern. Das ist das, was die Events bei der UI schon machen. Das, was der Button macht, ist nicht im Button sondern außerhalb. Das ginge hier also auch.
Der 2. Weg wäre der Richtige. Und da Du ja eigentlich nichts hinzu fügst, brauchst Du da viele Klasse schlicht nicht mehr und das vereinfacht sich alles massiv. Das können wir dann auch einmal machen. Dazu betrachten wir aber einfach einmal alles, was Du da bisher hast:
Klasse ActionEvent. Ja, ist denn ein ActionEvent ein JFrame? Und ist die Instanz wirklich ein Event? Das ist doch erst einmal einfach nur ein Programm. Also ist es das ActionEventTestProgram oder so. Und das hat eine main Methode um es zu starten. Und diese erzeugt eine neue Instanz von der Klasse:
Java:
public class ActionEventTestProgram {
public ActionEventTestProgram(){
}
public static void main(String[] args) {
new ActionEventTestProgram();
}
}
Nun können wir da noch den Code rein packen, den Du haben wolltest:
Das ist dann erst einmal die Erzeugung einen JFrame mit dem Inhalt:
Code:
import javax.swing.*;
public class ActionEventTestProgram {
public ActionEventTestProgram(){
JFrame frame = new JFrame("ClickFrame");
JPanel southPanel = new JPanel();
JCheckBox checkbox = new JCheckBox();
southPanel.add(new JLabel("switch"));
southPanel.add(checkbox);
frame.add(southPanel);
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
public static void main(String[] args) {
new ActionEventTestProgram();
}
}
Nun fehlt noch, das ja etwas passieren soll, wenn man die Checkbox drückt. Das muss da natürlich auch noch rein. Das ist dieser addItemListener. Das ist ein funktionales Interface, d.h. da wird nur eine Methode benötigt und die kann man als Methodenreferenz oder als Lambda Ausdruck haben. Dazu reicht es aber, wenn wir uns die betreffende Methode einfach einmal aus Deinem Listener heraus kopieren:
Code:
public void itemStateChanged(ItemEvent e){
Color color;
if(e.getStateChange() == ItemEvent.SELECTED){
color = Color.RED;
//wie greife ich hier auf die hintergrundfarbe zurück?
}else{
color = Color.GREEN;
//wie greife ich hier auf die hintergrundfarbe zurück?(
}
}
Erst einmal ist der Name etwas blöd ... Was macht die Methode? Bzw. was soll diese machen? Sie Soll die Farbe wechseln beim Checkbox Wechsel. Also sowas wie switchColorOnCheckboxStateChangeEvent (Ja, wird etwas lang - evtl. fällt Dir ein besserer Name ein. Mir gefällt der On... Part nicht, denn der gehört da nicht hin ... ich mache noch ein Post mit einem Refactoring!). Können wir also umbenennen.
Dann haben wir aber weiter das Problem, dass wir ja auf die Elemente zugreifen können wollen. Das sind aber bisher nur lokale Variablen im Konstruktor. Das machen wir einfach zu Instanzvariablen.
Und zuletzt wollen wir noch den Listener eintragen. Und schon haben wir folgenden Code:
Code:
import javax.swing.*;
import java.awt.*;
import java.awt.event.ItemEvent;
public class ActionEventTestProgram {
private JFrame frame;
private JPanel southPanel;
private JCheckBox checkbox;
public ActionEventTestProgram(){
frame = new JFrame("ClickFrame");
southPanel = new JPanel();
checkbox = new JCheckBox();
checkbox.addItemListener(this::switchColorOnCheckboxStateChangeEvent);
southPanel.add(new JLabel("switch"));
southPanel.add(checkbox);
frame.add(southPanel);
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
public static void main(String[] args) {
new ActionEventTestProgram();
}
public void switchColorOnCheckboxStateChangeEvent(ItemEvent e){
Color color;
if(e.getStateChange() == ItemEvent.SELECTED){
color = Color.RED;
//wie greife ich hier auf die hintergrundfarbe zurück?
}else{
color = Color.GREEN;
//wie greife ich hier auf die hintergrundfarbe zurück?(
}
}
}
Jetzt wird die Farbe noch nicht geändert, aber Du hast jetzt die Möglichkeit, auf frame und southPanel zuzugreifen um diese zu verändern.
Und nun noch als letzter Schritt: Diese blöde Methode. Im Augenblick macht die noch zwei Dinge, die diese Namensgebung schwer macht.
Was uns noch etwas fehlt ist eine "Separation of Concerns". Es ist üblich, dass man gewisse Funktionalitäten aufteilt. Da finden sich dann diverse Pattern wie MVC oder MVVM. Da wir hier aber so gut wie nichts zu trennen hätten, lassen wir alles zusammen und ignorieren das erst einmal. Aber evtl. willst Du MVC einmal nachlesen.
Was wir auf jeden Fall haben, ist eine Methode, die aufgerufen wird, wenn sich da an der Checkbox etwas ändert. Die nenne ich immer gerne on.... Also wäre das hier eine Methode onCheckboxStateChange.
Dies soll etwas machen - und zwar die Hintergrundfarbe ändern. Das sollte eine eigene Methode sein: setBackgroundColor(Color).
Damit wird die Methode nur noch ein einfaches:
1. Möglichkeit: Das, worauf du zugreifen willst, musst Du übergeben. Also wenn Du in der Instanz von CheckBoxListener auf etwas zugreifen willst, dann musst Du es dem geben. Da es aus dem Frame kommt, musst Du das entsprechende Element halt erst an die Checkbox übergeben und von dort halt dann weiter an den Listener.
Erstmal danke für die sehr ausführliche und gut heranführende Antwort. Hat mir sehr geholfen. Ok, also könnte ich theoretisch auch einfach eine getter Schreiben mit der man dann die Hintergrundfarbe bekommt.
Ahh ok, also wenn ich die Methoden in einer Klasse schreibe ist es echt deutlich einfache . Gibt es bestimmte Ansatzpunkte wann man eigene Klassen dafür schreiben sollte?
Was uns noch etwas fehlt ist eine "Separation of Concerns". Es ist üblich, dass man gewisse Funktionalitäten aufteilt. Da finden sich dann diverse Pattern wie MVC oder MVVM. Da wir hier aber so gut wie nichts zu trennen hätten, lassen wir alles zusammen und ignorieren das erst einmal. Aber evtl. willst Du MVC einmal nachlesen.
Dies soll etwas machen - und zwar die Hintergrundfarbe ändern. Das sollte eine eigene Methode sein: setBackgroundColor(Color).
Damit wird die Methode nur noch ein einfaches:
Bei dem folgenden Ausdruck: checkbox.addItemListener(this::switchColorOnCheckboxStateChangeEvent);
benötigt der addItemListener eine Instanz, welche ein funktionales Interface implementiert. Bei Funktionalen Interfaces handelt es sich um ein Interface, bei dem genau eine Methode implementiert werden muss.
Ab Java 8 kann man für funktionale Interfaces auch angeben:
a) Eine Lambda Expression (teilweise als "anonyme Methode" bezeichnet).
b) eine Methodenreferenz.
Bei dem this::switchColorOnCheckboxStateChangeEvent handelt es sich um eine Methodenreferenz. Die Referenz verweist auf die Methode switchColorOnCheckboxStateChangeEvent von this.
Ahh ok, also wenn ich die Methoden in einer Klasse schreibe ist es echt deutlich einfache . Gibt es bestimmte Ansatzpunkte wann man eigene Klassen dafür schreiben sollte?
Eigene Klassen machen immer dann Sinn, wenn Du da ein Verhalten oder einen Zustand hinzufügen willst und dies dann wirklich eine neue Art von Objekt ergibt. Das ist das, was @Blender3D gezeigt hat: Er hat sozusagen ein Control erstellt, welches ein spezielles Verhalten hat.
Das ist technisch möglich, aber bei der objektorientierten Entwicklung hat man feststellen müssen, dass die Vererbung deutlich überbewertet ist. Dies hat dazu geführt, dass hier viele Regeln aufgestellt wurden, die teilweise sehr strikt sind (z.B. Liskovs Substitution Principle) und teilweise gute Ratschläge geben (z.B. Composition over Inheritance). Letzteres ist hier angewendet worden. Du willst ja eigentlich keine Klasse haben, die JFrame erweitert und sich genau wie ein JFrame verhält. So soll dein konkretes Fenster einen bestimmten Title haben und der soll nicht von außen geändert werden. Daher ist hier Composition vorzuziehen, d.h. Deine Klasse erbt nicht von JFrame sondern sie hat ein JFrame. Damit ist das dann auch gekapselt und du kannst die Methoden nach außen geben, die Du willst und gibst nicht automatisch alles nach außen, was JFrame nach außen gibt. Da wäre das Stichwort Kapselung.
Hier sind also immer mehrere Dinge zu sehen:
a) technische Machbarkeit
b) Was ist zweckmäßig - hier würde ich den Punkt einfach als Clean Code / Clean Architecture umschreiben.
Das ließe sich auch auf den Code von @Blender3D anwenden: Soll sein Control sich wie ein JPanel verhalten? Macht es da z.B. Sinn, dass da noch weitere Elemente hinzu gefügt werden? Evtl. macht es also wenig Sinn, dass hier von JPanel abgeleitet wurde. Statt dessen soll es ggf. nur das Verhalten eines normalen Controls haben, also wäre ggf. java.awt.Component besser geeignet gewesen und es hätte dann nur ein JPanel intern besessen.
Das aber nur als zweites Beispiel bezüglich dieses Punktes. Das soll keine Kritik am Code selbst sein - das ist ein schnell zusammengeschriebener Code, der (Dir) etwas bestimmtes zeigen sollte und da wäre so eine "Verkomplizierung" schlicht kontraproduktiv!
Ist das etwas deutlich geworden? Oder sollte man dies noch etwas mehr im Detail ausführen?
