Methodenaufrufe im Konstruktoren

[memo1990]

Guten Abend Community,

heute habe ich erfahren, dass man (überschreibbare) Methoden nicht in Konstruktoren aufrufen sollte, da evtl. die Methoden auf Variablen zugreifen, die noch nicht initialisiert sind, was sinn macht.

Jetzt frage ich mich aber, warum in Tutorials Quellcodes gezeigt werden, wo genau das gemacht wird. Gutes Beispiel ist das ableiten eines JFrames. Im Konstruktor werden die Komponenten initialisiert und in das JFrame hinzugefügt, wodurch ich die add()-Methode aufrufen muss.

Was ist eure Meinung dazu?

MfG Mehmet B.

 

[Robat]

Was ist eure Meinung dazu?

Nicht von JFrame erben. Du machst ja auch nicht für jeden String eine eigene Klasse nur weil du einen neuen String erzeugen willst
Außerdem: Du überschreibst die Methode add() ja nicht. Demnach sollte es kein Szenario geben wo es da zu Problemen kommen kann.

Was zu Problemen führen kann ist folgendes Szenario:

abstract class Base {
    Base() {
        methodA();
    }

    abstract void methodA();
}
class Bar extends Base {
    String name;

    Bar() {
        this.name = "Max";
    }

    @Override
    void methodA() {
        System.out.println(name);
    }
}
new Bar();

Im Konstruktor der Klasse Base ist die Bar Klasse noch nicht mit der Initialisierung der Member fertig. Dennoch wird die Methode methodA() aufgerufen und gibt null aus, weil name noch kein Wert zugewiesen wurde. Wenn du dir jetzt vorstellst dass eben nicht nur etwas ausgegeben wird, sonder Operationen mit name durchgeführt werden, kann es schnell (z.B) zu einer NPE kommen.

 

[mrBrown]

Jetzt frage ich mich aber, warum in Tutorials Quellcodes gezeigt werden, wo genau das gemacht wird.
[...]
Was ist eure Meinung dazu?

Die meisten Tutorials sind einfach schlecht (ganz besonders bei YouTube...) Und dadurch, dass es viele so machen, gucken sich das viele für ihr eigenes Tutorial ab, und es verbreitet sich weiter.



In dem JFrame-Fall sind es drei verpönte Dinge gleichzeitig:
Das Erben von JFrame an sich, das Aufrufen von überschriebenen Methoden und das weitergeben von this (was in add passiert).

 

[memo1990]

Das mit dem ableiten eines JFrame habe ich in einem Fachbuch gelernt (Jetzt lerne ich Java 7, von Péter Müller u. Dirk Louis).

Nicht von JFrame erben.

Wieso sollten die es dann so lehren? Was ist außerdem falsch daran, von JFrame abzuleiten? Der Swing-Builder in NetBeans leitet ebenfalls von JFrame ab.

Du machst ja auch nicht für jeden String eine eigene Klasse nur weil du einen neuen String erzeugen willst.

Ich will an der Klasse auch nichts anpassen oder erweitern.

 

[mrBrown]

Ich will an der Klasse auch nichts anpassen oder erweitern.

Eben: du willst die Klasse nur nutzen - nicht anpassen oder erweitern.
Also: kein „extends“ (was erweitern wäre), sondern einfach nutzen


(siehe auch https://de.wikipedia.org/wiki/Komposition_an_Stelle_von_Vererbung)

 

[memo1990]

Ich erweitere JFrame doch, indem ich Komponenten wie JButton, usw. hinzufüge.

 

[mrBrown]

Nein, du nutzt es nur, durch Dinge hinzufügen verändertes du ja nicht ein JFrame an sich.


Analog: wenn du eine Liste von Elemente brauchst, nutzt du ja auch einfach nur eine Liste, und schreibst nicht eine extra Klasse, nur um „extends ArrayList“ zu schreiben

 

[memo1990]

Tut mir leid wenn ich nochmal widerspreche bzw. nachhacke. Wenn ich doch in einer Klasse, die von JFrame abgeleitet ist, neue Attribute (die Komponenten) hinzufüge, verändere ich in dem Fall doch die JFrame.

Abseits davon. Wieso wird im Swing-Builder von NetBeans der Code so generiert oder es in Lehrbüchern so gezeigt, wenn man von JFrame nicht ableiten sollte?

MfG Mehmet B.

 

[mrBrown]

Tut mir leid wenn ich nochmal widerspreche bzw. nachhacke. Wenn ich doch in einer Klasse, die von JFrame abgeleitet ist, neue Attribute (die Komponenten) hinzufüge, verändere ich in dem Fall doch die JFrame.

Nein, Komponenten hinzufügen ist nicht das gleiche, wie eine Klasse erweitern.
Du willst einfach nur Komponenten zu einem Fenster hinzufügen (also ein Objekt der Klasse JFrame verändern), dazu musst du nicht die Klasse verändert (was JFrame erweitern wäre).

Mal ein "Echt-Welt"-Beispiel: Einkaufskorb und Waren.
Baust du dir für jeden Einkauf einen neuen Einkaufskorb, je nachdem welche Waren du reinlegst?
Oder nutzt du einfach nur einen Einkaufskorb, und legst Waren rein?

Abseits davon. Wieso wird im Swing-Builder von NetBeans der Code so generiert oder es in Lehrbüchern so gezeigt, wenn man von JFrame nicht ableiten sollte?

Weil viele es eben falsch machen

In den "richtigen" Fachbüchern wirst du immer wieder auf Composition over Inheritance stoßen, und eben dieses Grundprinzip gilt auch JFrames.

 

[Flown]

Das mit dem ableiten eines JFrame habe ich in einem Fachbuch gelernt (Jetzt lerne ich Java 7, von Péter Müller u. Dirk Louis).

Wenn es ein gutes "Fachbuch" wäre, dann stünde ganz am Anfang, dass Ableitung genutzt wird um den Code kurz zu halten.

 

[memo1990]

Ich glaube ich habe es verstanden wie ihr das meint. Vorallem das mit dem Echt-Welt-Beispiel.

Ich habe mich auch falsch ausgedrückt. Ich verändere nicht die Klasse JFrame an sich (das Verhalten eines JFrame), ich erweitere es um Komponenten.

Weil viele es eben falsch machen

Naja, NetBeans, das unteranderem von Orcale kommt, machen es also auch falsch?

Wenn es ein gutes "Fachbuch" wäre, dann stünde ganz am Anfang, dass Ableitung genutzt wird um den Code kurz zu halten.

Ja das ist mir Bewusst.

 

[mihe7]

Oh, mein Lieblingsthema...

Wenn ich doch in einer Klasse, die von JFrame abgeleitet ist, neue Attribute (die Komponenten) hinzufüge, verändere ich in dem Fall doch die JFrame.

Du änderst dadurch weder etwas an der Implementierung von JFrame, noch erweiterst Du Funktionalität.

Gehen wir mal von folgendem Beispiel aus (Skizze):

public class Hauptfenster extends JFrame {
    public Hauptfenster() {
        JLabel greeting = new JLabel(" ");
        JTextField name = new JTextField(20);
        JButton button = new JButton("Greet!");
        button.addActionListener(e -> greeting.setText("Hallo " + name.getText()));
        setLayout(new FlowLayout(FlowLayout.LEFT, 10, 10));
        add(name); add(button); add(greeting);
        setTitle("Hauptfenster");
        setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    }
}

Die Klasse der Hauptfenster erweitert JFrame um ein Eingabefeld, eine Schaltfläche sowie ein Label, das einen freundlich begrüßt, sobald man die Schaltfläche anklickt.

Also, alles in Ordnung, oder?

Spoiler

Nein, alles falsch.

Da Hauptfenster Subtyp von JFrame ist, muss sich Hauptfenster wie ein JFrame verwenden lassen, z. B. so:

public void reset(JFrame frame) {
    frame.setTitle("");
    frame.setCloseOperation(JFrame.HIDE_ON_CLOSE)
    frame.getContentPane().setLayout(new BorderLayout());
    frame.getContentPane().removeAll();
}

Wende ich diese Methode auf ein Hauptfenster-Objekt f an, dann sind alle zuvor gemachten Zusicherungen weg (enthält ein Eingabefeld, eine Schaltfläche, ...) Im Prinzip unterscheidet sich das Hauptfenster-Objekt dann nicht mehr von einem new JFrame().

Ebenso gut hätte man

public class Hauptfenster extends JFrame {
}

implementieren können.

Um mal ein Positiv-Beispiel zu nennen: Erweiterung eines JPanels um die Darstellung eines Hintergrundbilds. Hierbei wird JPanel tatsächlich um Funktionalität erweitert.

Naja, NetBeans, das unteranderem von Orcale kommt, machen es also auch falsch?

Die Frage ist nicht, von wem es kommt.

 

[memo1990]

Danke für deine Erklärung @mihe7. Das habe ich soweit verstanden. Das Trifft in dem Fall auf die Klasse JFrame zu, da Sie so implementiert ist.

Wenn ich aber aber folgenden Code schreibe, ist es eine typische Vererbung/Erweiterung:

Spoiler: Java-Code

class Mitarbeiter {
    private String name;
    private int gehalt;
 
    Mitarbeiter(String name, int gehalt) {
        this.name = name;
        this.gehalt = gehalt;
    }
 
    public String getName() {
        return name;
    }
 
    public String getGehalt() {
        return gehalt;
    }
 
    public String getRang() {
        return "Mitarbeiter";
    }
}

class Azubi extends Mitarbeiter {
    private int ausbildungsjahr;
 
    Azubi(String name, int gehalt, int ausbildungsjahr) {
        super(name, gehalt);
        this.ausbildungsjahr = ausbildungsjahr;
    }
 
    @Override
    public String getRang() {
        return "Auszubildender";
    }
}

Zum eigentlichen Thema zurück. Wenn ich weiß wie die Methode implementiert, also sie auf kein Attribut zurückgreift, wo der Konstruktor noch nicht initialisieren haben könnte, sollte es ja kein Problem darstellen die Methode im Konstruktor aufzurufen. Aber ich denke mal das ist ein schlechter Programmierstil.

Ich werde mir auch das "Komposition an stelle von Vererbung" bzw. "Open/Closed Prinzip" genauer anschauen. Danke dafür.

 

[Javinner]

@memo1990
Kleine Verbesserung am Code:
statt..

public String getRang() {
    return "Mitarbeiter";
}

lieber..

public String getRang() {
    return getClass().getSimpleName();
}

Weiterhin..

public String getGehalt() {
    return gehalt;
}

sollte ein int zurückgeben, schau dir den primitiven Typ an
Im Konstruktor würde ich die Parameter auf "Null" prüfen. Hat sich bewehrt.

Class Objects#requireNonNull(T obj)

 

[mrBrown]

@memo1990
Kleine Verbesserung am Code:
statt..

public String getRang() {
    return "Mitarbeiter";
}

lieber..

public String getRang() {
    return getClass().getSimpleName();
}

Wobei das eher eine Verschlimmerung und keine Verbesserung ist
Code hat nichts in für Menschen gedachten Ausgaben zu suchen (Ausnahmen bestätigen die Regeln, aber in so einem Fall gilt es)

 

[memo1990]

Weiterhin..

public String getGehalt() {
    return gehalt;
}

sollte ein int zurückgeben, schau dir den primitiven Typ an

Ja ich weiß, war nur ein Typfehler. Da ich es schnell zusammengeschrieben habe, ist es mir nicht aufgefallen. Aber danke.

Im Konstruktor würde ich die Parameter auf "Null" prüfen. Hat sich bewehrt.

Danke für den Tipp.

 

[mihe7]

Wenn ich aber aber folgenden Code schreibe, ist es eine typische Vererbung/Erweiterung

Lassen wir das "typisch" weg und sagen wir ein eingeschränktes Ja

Wenn ich weiß wie die Methode implementiert, also sie auf kein Attribut zurückgreift, wo der Konstruktor noch nicht initialisieren haben könnte, sollte es ja kein Problem darstellen die Methode im Konstruktor aufzurufen.

Es geht darum, dass Du nicht wissen kannst, was abgeleitete Klassen machen. Siehe dazu das Beispiel von @Robat.

 

[Javinner]

Wobei das eher eine Verschlimmerung und keine Verbesserung ist
Code hat nichts in für Menschen gedachten Ausgaben zu suchen (Ausnahmen bestätigen die Regeln, aber in so einem Fall gilt es)

Jetzt lese ich den Satz bereits zum Dritten Mal und weiß immer noch nicht, wie es gemeint ist

 

[mihe7]

@Javinner Wenn Du die Klasse Mitarbeiter in Employee umbenennst, bekommst Du als Rang "Employee" geliefert. Der Anwender will aber "Mitarbeiter" sehen.

 

[Javinner]

@mihe7
Ich ging davon aus, dass die Klasse Mitarbeiter nicht verändert wird und die Bezeichnung nur der Übung dient. Wenn man denn mehrere Sprachen einführen will, dann muss man a) der Klasse die Region mitteilen und b) die Methode getRang() eh anpassen.

Spoiler

public class Employee
{

    public static void main(String[] args)
    {
       
        String german = Locale.getDefault().getISO3Language();
        Mitarbeiter mitarbeiter = new Mitarbeiter(german);
        System.out.println(mitarbeiter.getRang());

        String english = Locale.ENGLISH.getISO3Language();
        Mitarbeiter employee = new Mitarbeiter(english);
        System.out.println(employee.getRang());


    }

}
/** Output */
Mitarbeiter
Employee

Aber hier gibt es bestimmt noch paar Herangehensweisen mehr und sicher auch einige schönere, als mein auf die Schnelle zusammengezimmertes Beispiel

 

[mihe7]

Wenn man denn mehrere Sprachen einführen will,

Es ging mir nicht um mehrsprachige Anwendung, sondern um den Satz von @mrBrown. Ich hätte Mitarbeiter besser in MeineSchöneMitarbeiterKlasse statt Employee umbenennen sollen

 

[mrBrown]

Jetzt lese ich den Satz bereits zum Dritten Mal und weiß immer noch nicht, wie es gemeint ist

Noch mal zur Erklärung, was ich meinte:
Der Klassenname ist ein Implementierungsdetail, den sollten höchstens andere Programmierer, aber keine "Nutzer" sehen.
Der Rang dagegen ist entweder als Ausgabe für irgendwen gedacht oder als Information für andere Programmiere, die die Klasse nutzen.
Im zweiten Fall ist das simpel: Ein String ist kein sinnvoller Datentyp, entweder man nutzt es da einen passenden, oder verzichtet drauf (wenn es nur der Klassenname ist, hat man diese Information ja eh ).

Im ersten Fall sollte die Ausgabe dann, weil sie Menschenlesbar ist, eben nicht vom Code abhängen. Im einfachsten Fall schreibt man einfach den String, der übersteht dann auch Refactorings und zB Vererbung. Im Idealfall kommen aber Menschenlesbare Dinge gar nicht in der Klasse vor (Single responsibility principle ), sondern dort nur ein sinnvoller Datentyp, der dann außerhalb in eine Menschenlesbare Form gebracht wird

 

[memo1990]

Lassen wir das "typisch" weg und sagen wir ein eingeschränktes Ja

Wieso ein eingeschränktes ja?

Es geht darum, dass Du nicht wissen kannst, was abgeleitete Klassen machen. Siehe dazu das Beispiel von @Robat.

Gut, das stimmt.

 

[mihe7]

Wieso ein eingeschränktes ja?

Durch die Klasse Azubi teilst Du Mitarbeiter in wenigstens zwei verschiedene Kategorien (=Klassen) ein. Nämlich solche Mitarbeiter, die Azubis sind und solche, die keine Azubis sind. Dann aber gibt es "den" Mitarbeiter nicht.

 

[memo1990]

Das ist folgender Code ein uneingeschränktes ja?!

Spoiler: Java-Code

abstract class Mitarbeiter {
    private String name;
    private String rang;
    private int gehalt;
   
    Person(String name, String rang, int gehalt) {
        this.name = name;
        this.rang = rang;
        this.gehalt = gehalt;
    }
   
    public String getName() {
        return name;
    }
   
    public String getRang() {
        return rang;
    }
   
    public int getGehalt() {
        return gehalt;
    }
}

class Geselle extends Mitarbeiter {
    private int berufsjahre;
   
    Mitarbeiter(String name, String rang, int gehalt) {
        super(name, rang, gehalt);
    }
   
    public int getBerufsjahre() {
        return berufsjahre;
    }
}

class Azubi extends Mitarbeiter {
    private int ausbildungsjahr;
    Azubi(String name, String rang, int gehalt, int ausbildungsjahr) {
        super(name, rang, gehalt);
        this.ausbildungsjahr = ausbildungsjahr;
    }
   
    public int getAusbildungsjahr() {
        return ausbildungsjahr;
    }
}

 

[mihe7]

Jetzt müssen wir differenzieren... Sieht man mal davon ab, dass die Berufsjahre nirgends gesetzt werden, würde ich dem - rein von der technischen Seite her - zustimmen: die Objekte können immer eindeutig einer der beiden Subklassen zugeordnet werden. Von der Konzeption her ist es eine ganz andere Frage, die sich aber nicht pauschal beantworten lässt.

Für eine Personalverwaltung taugt das Modell z. B. nicht. Beispiel: Du hast einen Azubi, nennen wir ihn mal Hans. Irgendwann ist der Kerl mit seiner Ausbildung fertig und bekommt den Gesellenbrief. Dann ist er Geselle. Damit hätte Hans in Deinem Modell mehrere Identitäten. Schizophrenie tut selten gut

Mit fällt ehrlich gesagt auch kein Fall ein, für den das angegebene Modell gut geeignet wäre, auch weil sich die Subklassen zu stark ähneln. Aber ich kann natürlich nicht ausschließen, dass es einen solchen Fall gibt.

 

[memo1990]

Jetzt müssen wir differenzieren... Sieht man mal davon ab, dass die Berufsjahre nirgends gesetzt werden, würde ich dem - rein von der technischen Seite her - zustimmen

Ja, da habe ich auf die Schnelle die dafür vorgesehene set-Methode vergessen. Aber es ging mir nur um die allgemeine Vorgehensweise.

Für eine Personalverwaltung taugt das Modell z. B. nicht. Beispiel: Du hast einen Azubi, nennen wir ihn mal Hans. Irgendwann ist der Kerl mit seiner Ausbildung fertig und bekommt den Gesellenbrief. Dann ist er Geselle. Damit hätte Hans in Deinem Modell mehrere Identitäten. Schizophrenie tut selten gut

Man könnte die Daten vom Objekt Hans (Typ Azubi) auslesen und in ein neues Objekt vom Typ Geselle instanziieren?! Wieso sollte er dann mehrere Identitäten haben?

Es streift zwar vom eigentlichen Thema ab, aber das Interessiert mich.

Zu der Aussage nochmal:

Es geht darum, dass Du nicht wissen kannst, was abgeleitete Klassen machen.

Doch, wenn ich alle Klassen, mit denen ich arbeite selbst schreibe/geschrieben habe.

 

[mrBrown]

Man könnte die Daten vom Objekt Hans (Typ Azubi) auslesen und in ein neues Objekt vom Typ Geselle instanziieren?! Wieso sollte er dann mehrere Identitäten haben?

Du hast dann irgendwann gleichzeitig Geselle{Hans} und Azubi{Hans}, für die auch noch gilt, dass Geselle{Hans} != Azubi{Hans}.
Die Auswirkung davon kann man verringern, aber warum nicht gleich ganz Einschänken?

zB: Eine Klasse Mitarbeiter (oder Person), die nur den Namen und eine Liste von Ereignissen enthält.
Beim Ausbildungsbeginn wird dann ein "AusbildungBegonnen"-Objekt hinzugefügt, zum Ende ein "AusbildungsEnde"-Objekt und ein "AnstellungBegonnen".
Die eine Person bleibt dann immer gleich und es wird nur gespeichert, was mit ihr passiert.

Doch, wenn ich alle Klassen, mit denen ich arbeite selbst schreibe/geschrieben habe.

Ja, schon - aber willst du deine Klassen wirklich so aufbauen, dass du immer jedes Detail aus allen Klassen um Kopf haben musst?

 

[mihe7]

Man könnte die Daten vom Objekt Hans (Typ Azubi) auslesen und in ein neues Objekt vom Typ Geselle instanziieren?! Wieso sollte er dann mehrere Identitäten haben?

Weil Objekte Identität besitzen. Du schreibst ja selbst: und in ein neues Objekt vom Typ Geselle ... - dieses Objekt hat eine andere Identität als das Objekt vom Typ Azubi. Ergo: zwei Identitäten für Hans. Abgesehen davon hast Du wenigstens zu dem Zeitpunkt die zwei Objekte, von denen @mrBrown gesprochen hat.

Doch, wenn ich alle Klassen, mit denen ich arbeite selbst schreibe/geschrieben habe.

Ja, und wenn Du jedesmal, also auch nach Jahren, nachschaust, ob es ein Problem geben könnte.

Weder beim einen, noch beim anderen Thema sind die Aussagen in Stein gemeißelt. Man kann begründen, warum man etwas so oder so macht. Nichts wird dadurch automatisch richtig oder falsch.

 

[memo1990]

Ja, und wenn Du jedesmal, also auch nach Jahren, nachschaust, ob es ein Problem geben könnte.

Habe den Satz jetzt mehrmals gelesen. Wie meinst du das?

 

[mihe7]

Die ursprüngliche Argument war, dass Du nicht wissen kannst, was die abgeleiteten Klassen machen. Das Gegenargument war, dass das schon der Fall wäre, wenn Du die Klassen alle selber schreibst.

Das ist richtig, Du musst allerdings sicherstellen, dass Du in der abgeleiteten Klasse nichts machst, was zu einem Problem führen könnte. Nach z. B. fünf Jahren(*) wirst Du die Details nicht mehr 100 %-ig aus dem Kopf kennen. Dem entsprechend musst Du immer im Code nachsehen.

(*) real bewegen wir uns im Bereich von Tagen/Wochen, je nachdem an wie vielen (Teil-)Projekten Du gleichzeitig arbeitest.

 

[memo1990]

Ja das stimmt wiederum.