Das, was Du brauchst, ist einfach etwas, das auch als Observer Pattern bekannt ist. Dann können sich andere informieren lassen über Änderungen. Also bei Dir z.B. über einen KLick auf den Button.@setelk das ist eine komplett Eigene Klasse, weil es auf einem Canvas dargestellt wird. Meine beste Idee ist bisher meinen Button als abstract zu machen und dann verschiedene Klassen pro Funktion zu haben, welche die action implmentieren
private JButton buttonName;
buttonName.addActionListener(e -> {
//doSomethingHere
});
//ohne lamda schreibweise
buttonName.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
}
});
Das, was Du brauchst, ist einfach etwas, das auch als Observer Pattern bekannt ist. Dann können sich andere informieren lassen über Änderungen. Also bei Dir z.B. über einen KLick auf den Button.@setelk das ist eine komplett Eigene Klasse, weil es auf einem Canvas dargestellt wird. Meine beste Idee ist bisher meinen Button als abstract zu machen und dann verschiedene Klassen pro Funktion zu haben, welche die action implmentieren
Danke, genau nach sowas habe ich gesucht.Das, was Du brauchst, ist einfach etwas, das auch als Observer Pattern bekannt ist. Dann können sich andere informieren lassen über Änderungen. Also bei Dir z.B. über einen KLick auf den Button.
Die Implementierung der einzelnen Aktionen hat ja auch nichts mit dem Button zu tun. Man sollte immer versuchen, Darstellung und Logik zu trennen - Du hast also einen Button, der eine Form der Darstellung ist. Dieser Button ist komplett unabhängig von den Dingen, die da gemacht werden. Daher gehört es nicht in den Button selbst rein.
Die Idee, hier mit Inheritance zu arbeiten, ist natürlich prinzipiell denkbar, aber es ist unüblich. Zur Trennung reicht hier - wie schon erwähnt - ein Oberserver Pattern aus, so dass man statt Inheritance eben Composition wählen kann (FCoI - Favor Composition over Inheritance).