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.
Designentscheidung von Attributen/Methoden im Falle von Vererbung
Ich stelle mir gerade eine etwas philosophischere Frage:
Eine Klasse "Elternklasse", hat gewisse Attribute. Diese sollten ja per JavaBean-Konvention immer private sein.
Nun gibt es aber eine Klasse "Kindklasse extends Elternklasse", die diese Attribute -logisch gesehen- auch besitzt. Dadurch, dass diese aber in "Elternklasse" private sind, kann die "Kindklasse" nicht direkt darauf zugreifen.
Nun meine Designfrage:
Setze ich die Attribute in "Elternklasse" auf protected, oder zwinge ich die "Kindklasse" dazu, per getter- und setter auf die Attribute zuzugreifen?
Was ist hier die sauberere Herangehensweise? Was meint ihr?
Nutz immer den meist Einschränkenden Acces Modifier, den du nutzten kannst.
Also bei Attributen immer private, durch Setter und Getter kannst du ja drauf zugreifen.
Wenn es nicht private ist, kannst du nicht kontrollieren was mit deinem Attribut in den ableiteten Klassen geschieht
Also, wie du bereits festgestellt hast ist die Standard-Java-Klasse so aufgebaut:
Java:
public class Something {
private Object valueA = null;
private Object valueB = null;
public Something() {
super();
}
public void getValueA() {
return valueA;
}
public void getValueB() {
return valueB;
}
public void setValueA(Object valueA) {
this.valueA = valueA;
}
public void getValueB(Object valueB) {
this.valueB = valueB;
}
}
Das ist "normal", aber ist von einem API-Design Sichtpunkt aus problematisch aus mehreren Gruenden.
Auf der einen Seite wollte der Author nicht dass der interne Zustand veraendert werden kann in dem die Klassenvariablen private sind, aber die Getter und Setter koennen alle von ableitenden Klassen ueberschrieben werden. Auf der anderen Seite koennen ableitende Klassen die Getter und Setter ueberschreiben, aber nicht den internen Zustand aendern. Das wird insbesondere problematisch wenn wir das Beispiel etwas ausbauen:
Java:
public class ComplexAction {
private int valueA = 0;
private int valueB = 0;
public ComplexAction(int valueA, int valueB);
public int performAction(int parameterA, int parameterB);
private int calculateValueC(int parameterA);
private int calculateValueD(int parameterB);
}
Wir haben hier eine relativ einfache Klasse welche mit ihrem internen Zustand etwas tut, sie ist nach dem Standar-Schema erstellt, erzeugt dadurch aber mehrere Probleme. Sie ist nicht als final markiert, ist aber quasi-final. An dieser Klasse wird man nie etwas veraendern koennen, weil ableitende Klassen immer den Code kopieren muessen. Wenn jetzt zum Beispiel die ableitende Klasse die Notwendigkeit hat calculateValueC abuzaendern, geht das nur in dem man performAction ueberschreibt, und den gesamten Code aus der Basisklasse kopiert. Oder wenn sich valueA dynamisch aendern soll zur Laufzeit, dann kann man ebenfalls nur den gesamten Code kopieren. Die Klasse ist quasi-final, an der wird man nichts erweitern.
Nun gibt es unterschiedliche Methoden diesen Zustand aufzuloesen.
Billigloesung: final
Java:
public final class ComplexAction {
private int valueA = 0;
private int valueB = 0;
public ComplexAction(int valueA, int valueB);
public int performAction(int parameterA, int parameterB);
private int calculateValueC(int parameterA);
private int calculateValueD(int parameterB);
}
Damit hat sich die gesamte Diskussion ueber Erweiterbarkeit erledigt.
Ich persoenlich hasse final zu einem groszen Grad, weil es teilweise wie Schokostreusel verwendet wird. Jeder der schon einmal JavaFX Steuerelemente erweitern musste wird mir da zustimmen. Ich weisz dass der akademische Ansatz ist alles final zumachen bis auf Widerruf, aber in der echten Welt steht ein solcher Ansatz meistens eher im Weg, weil man nicht jeden Anwendungsfall abdecken kann. Es ist also eher mit Vorsicht zu machen meiner Meinung nach.
Billigloesung: protected
Java:
public final class ComplexAction {
protected int valueA = 0;
protected int valueB = 0;
public ComplexAction(int valueA, int valueB);
public int performAction(int parameterA, int parameterB);
protected int calculateValueC(int parameterA);
protected int calculateValueD(int parameterB);
}
Hier ist eine weitere billige Loesung welche aber Erweiterbarkeit erlaubt, einfach alles protected machen. Ich persoenlich ahbe mir genau das angewoehnt, weil ich dem Grundsatz folge "Wenn man eine Klasse erweitern will, braucht man auch Zugriff auf den internen Zustand". Es gibt da ein paar Ausnahmen, aber im groszen und ganzen sehen alle meine Klassen so aus, weil es beim erweitern einfach keine Probleme aufwirft, und ich auch beim testen die protected Methoden einzeln aufrufen und testen kann.
Natuerlich muss man dann hier beachten dass das alles irgendwie API ist, und wenn man daran was aendert brechen ableitende Klassen. Da muss man dann dementsprechend sein API-Versprechen und das eigene Verhalten anpassen und legen.
Desweiteren hat man ein Problem wenn die Werte irgendwie limitiert sind, zum Beispiel diese duerfen nur zwischen -5 und 5 liegen, dann kann man dies in der Basisklasse nicht wirklich garantieren dass dem so ist.
Komplexe Loesung: Kontrollierter Zugriff
Java:
public class ComplexAction {
private int valueA = 0;
private int valueB = 0;
public ComplexAction(int valueA, int valueB);
public int performAction(int parameterA, int parameterB);
protected int calculateValueC(int parameterA);
protected int calculateValueD(int parameterB);
protected final int getValueA();
protected final int getValueB();
protected final void setValueA(int valueA);
protected final void setValueB(int valueB);
}
Man kann aber auch den Zurgiff fuer ableitende Klassen erlauben in dem man diese ueber geschuetzte Getter und Setter bereitstellt. In diesem Fall kann eine ableitende Klasse die Werte holen und auch uebershreiben, aber nur durch die nicht ueberschreibbaren Getter und Setter. Dadurch kann die Basisklasse auch versprechen dass dieser Werte immer konform sind. Ebenfalls kann eine ableitende Klasse hier die einzelnen Schritte der Berechnung ueberschreiben.
Das Thema selbst ist sehr komplex, dass war jetzt so ein kurzer Umriss. Ich arbeite seit Ewigkeiten aneinem Tutorial zu dem Thema, ich muss das undebingt mal fertig machen.
Eine Klasse "Elternklasse", hat gewisse Attribute. Diese sollten ja per JavaBean-Konvention immer private sein.
Nun gibt es aber eine Klasse "Kindklasse extends Elternklasse", die diese Attribute -logisch gesehen- auch besitzt. Dadurch, dass diese aber in "Elternklasse" private sind, kann die "Kindklasse" nicht direkt darauf zugreifen.
Die erbende Klasse sollte eigentlich nicht auf Attribute der Elternklasse zugreifen müssen, sonst wäre die Elternklasse unvollständig. Die erbende Klasse stellt ja normalerweise einen Spezialfall der Elternklasse dar. Sprich: die Klasse "Auto" kümmert sich um alles, was ein Auto ausmacht. Die erbende Klassen "DreierBMW" beinhaltet das, was einen DreierBMW von allen anderen Autos unterscheidet.
Was aber durchaus öfter vorkommen kann wäre, daß die Elternklasse auf Attribute – über abstrakte Methoden – der erbenden Klasse zugreift. Die Elternklasse muß dann natürlich auch abstrakt sein. So könnte die Klasse Auto z.B. eine abstrakte Methode (gerne protected) bereitstellen, die z.B. Masse und Motorleistung liefert, um das Beschleunigungsverhalten bei Aufruf der Methode gibGas() adäquat nachzubilden.
Ich habe von Programmierung ja eigentlich gar keine Ahnung, aber in meinem Projekt habe ich ein oder zweimal ein Konstrukt, wo ich eine abstrakte Elternklasse habe und die erbenden Klassen überschreiben lediglich eine abstrakte Methode, in der sie eine Enumeration zurückgeben.
"Die erbende Klasse sollte eigentlich nicht auf Attribute der Elternklasse zugreifen müssen, sonst wäre die Elternklasse unvollständig."
Das versteh ich jetzt nicht ganz. Meiner Meinung nach kann es durchaus spezialisierte Eigenschaften der abgeleiteten Klasse geben, welche sich auf Eigenschaften der Super-Klasse beziehen. Oder meinst du da ganz was Anderes?
Grundsätzlich bin ich der Meinung, dass im Normalfall alles, was eine nicht abstrakte Klasse ausmacht, auch über public Methoden verfügbar und angesteuert werden sollte. Nur in sehr seltenen Fällen hab ich was gefunden, wo es sinnvoll war, es nur für ableitende Klassen verfügbar zu machen.
Idealerweise vielleicht, aber nicht immer. Wenn wir zum Beispiel folgende Klasse annehmen:
Java:
public class Something {
private Object value = null;
public Something(Object value) {
super();
this.value = value;
}
public Result performAction() {
// value is used here.
}
}
Wenn ich jetzt den Fall habe dass ich performAction anpassen muss, muss ich value im Konstruktor der abgeleiteten Klasse fangen und als neues Klassenmitlgied deklarieren. Wenn ich dann noch will dass sich value zur Laufzeit aendern koennen soll (unabhaengig davon ob es aus Sicht der Basisklasse Sinn macht oder nicht, ich habe diesen Anwedungsfall), kann ich nur noch mit Reflektion arbeiten um dieses Feld umzusetzen. Das ist das was ich mit "quasi-final" meinte. Die meisten Klassen sind so gebaut, aber erweitern kann man daran nichts mehr ohne sich teilweise die Finger zu brechen. Das ist dann, meiner Meinung nach, schlechtes API Design.
Oder nehmen wir einen Werte-Container welcher als "Fertig" angesehen wurde vom Entwickler:
Java:
public class Container {
private Object value = null;
public Something(Object value) {
super();
this.value = value;
}
public final Object getValue() {
return value;
}
}
So, jetzt will ich aber value dynamisch laden nach Bedarf wenn es wirklich gebraucht wird. Das Beispiel ist nichmal an den Haaren herbeigezogen, faules Nachladen braucht man alle naselang, und muss man alle naselang mal nachruesten (musste ich schon in einigen Bibliotheken machen, und wer hat schon die Zeit auf den Entwickler zu warten?).
Ja und Nein. Von einer reinen Klassenableitungshierarchie her, ja. In der Realitaet werden aber ableitende Klassen auch verwendet um zusaetzliche Funktionalitaet und Kompatibilitaet nachzuruesten, nachzureichen oder zu implementieren. Faules Nachladen zum Beispiel, oder dynamische Aenderungen, oder das implementieren einer zusaetzlichen Schnittstelle. Fuer all das braucht man, auf die ein oder andere Art, Zugriff auf den internen Zustand der Klasse. Wenn man diesen nicht von der Elternklasse gestellt bekommt, dann nutzt man entweder Tricks (fangen und neudeklarieren der Werte im Konstruktor), Relefktion oder man beginnt Code zu kopieren (man ist ja als erster im ClassLoader und gewinnt damit jeden Streit).
Sprich: die Klasse "Auto" kümmert sich um alles, was ein Auto ausmacht. Die erbende Klassen "DreierBMW" beinhaltet das, was einen DreierBMW von allen anderen Autos unterscheidet.
Selbst in diesem Beispiel ist es schwierig eine Linie zu ziehen. Es sagt sich so leicht "DreierBMW muss nur die Sachen aendern die es von anderen Autos unterscheidet", das ist aber so ziemlich *alles*. Also "Auto" muss in deinem Beispiel schon eine abstrakte Klasse sein wo quasi nichts darin passiert und alles durch die ableitenden Klassen bestimmt wird. Das Beispiel geht aber hier am Thema vorbei, meiner Meinung nach.
Das ist auch ein Thema in Effective Java: "Entwerfen und dokumentieren Sie für Vererbung oder verbieten Sie sie." Es folgt direkt auf das Thema: "Ziehen Sie Komposition der Vererbung vor".
Das Resümee daraus ist, dass es nicht ganz trivial ist, eine Klasse zu entwerfen, die für Vererbung geeignet ist. Das hast du (@Robert Zenz) in deinem Beitrag ja schön ausgeführt.
Das ist richtig. Meiner Erfahrung nach ist es aber besser eine "offene" Klasse zu haben welche nicht fuer Vererbung entworfen war (und dementsprechend ein paar Probleme hat oder macht), als eine final Klasse zu haben welche es von Haus aus verbietet (weil dann kopierst du erstrecht Code, oder wirfst alles weg und nimmst etwas anderes, oder machst es erst selbst). Ich war einfach zu oft am falschen Ende von final Klassen als das ich dem positiv gegenueber stehen koennte. Natuerlich kann es Sinn machen, aber die Verwendungen in die ich bis jetzt immer gelaufen bin waren entweder "alles final ohne Fragen", oder was viel, viel frustriender ist "Mh, ich habe schon lange nicht mehr final getippt, vielleicht sollte ich da welche hinmachen, OOP Design und so". Ein Beispiel dafuer ist JavaFX, aber gut, JavaFX hat viele Probleme neben final. Ein anderes Beispiel ist eine Bibliothek welche unter anderem von Spring eingesetzt wird. Diese stellt Kommunikation mit einem bestimmten Dienst her, und dieser Dienst unterstuetzt auch Filtern in der Anfrage, aber die Bibliothek nicht. Nachruesten im eigenen Projekt? Alles final. Ticket aufmachen? Ist schon seit drei Jahren offen. In die Bibliothek hinein bauen und hoffen dass der Merge und der naechste Release zeitnah kommen (von Diskussionen mal abgesehen)? Ich glaube nicht. Kopie lokal halten? Ja, koennte man machen, muss man pflegen (war in dem Projekt nicht ohne). Also, Ticket aufmachen und hoffen dass die Datenmenge nie zu grosz wird.
Das trifft natuerlich alles nur zu wenn die Klassen nicht 100% das Benutzerszenario treffen oder diese Fehler haben oder man Unzulaenglichkeiten ausbessern muss. Also die POJO-Modell-Klassen in der Desktop-Applikation werden das Problem nicht haben, aber alles auf dem irgendwie aufgebaut wird, jede Bibliothek, jedes Framework, jede Klasse welche zwischen Projekten geteilt wird, ist ein guter Kandidat diese eher offen zu halten als geschlossen. Von mir aus auch mit einem API-Versprechen von "was protected ist ist intern, dein Problem wenn es bricht".
Selbst in diesem Beispiel ist es schwierig eine Linie zu ziehen. Es sagt sich so leicht "DreierBMW muss nur die Sachen aendern die es von anderen Autos unterscheidet", das ist aber so ziemlich *alles*. Also "Auto" muss in deinem Beispiel schon eine abstrakte Klasse sein wo quasi nichts darin passiert und alles durch die ableitenden Klassen bestimmt wird.
Naja...ich würde erst gar nicht auf die Idee kommen, "Auto" nicht abstrakt machen zu wollen. Das Vorgehen, daß die erbenden Klassen der Elternklasse nur andere Parameter mitteilen und die Elternklasse die Tätigkeit dementsprechend anpasst, mag ich eigentlich.
Das funktioniert aber auch nur dann so richtig gut, wenn man vorher schon weiß oder wenigstens in Betracht gezogen hat.
Ich habe von Programmierung ja, wie bereits gesagt, eigentlich keine Ahnung. Aber ich vermute mal sehr stark, daß die meisten solcher Vererbungskollisionen aus zwei Gründen entstehen:
Entwickler denkt über sein Vorhaben zu wenig nach, bevor er in die Tasten haut (wie du schon sagtest: mieses API-Design).
Klassen werden für Zwecke fremdvergewaltigt, für die sie nie geschrieben wurden.
Wenn ich eine Bibliothek mit lauter Fahrzeugen habe, die eigentlich nur verschiedene PKW nachbilden soll, und mir daraus aber unbedingt Lastkraftwagen oder Bulldozer und schwere Kettenfahrzeuge schnitzen will, dann ist das einfach Murks. Wenn man dann aus der abgeleideten Klasse in der Elternklasse rumpfuschen will/muß würde ich das als deutliches Zeichen "Zum Holzweg hierlang" ansehen.
