Unabhängige Auslieferung bei Vererbung

langhaar!

Bekanntes Mitglied
Hallo,

in unserem Unternehmen gibt es auf hoher Ebene starke Ressentiments gegen Vererbung.
Argumentiert wird damit, dass eine Vererbung
- im Gegensatz zu einer losen Kopplung durch Methoden -
eine starke Bindung von Vater- und Kindklassen herstellt.

"bei der Vererbung gibt es eine undefinierte aber sehr starke Bindung zischen Oberklasse und erbender Klasse.
Bekannt ist in diesem Zusammenhang das Kopieren von Konstanten von der oberen Klasse in die erbende Kasse."

Aufgrunddessen sollen Änderungen an Oberklassen ohne Kentnisse der Unterklassen kaum möglich sein.
Umgekehrt ebenso. Bei einer Änderung der Oberklasse müssten auch alle Kindklassen erneut getestet werden.

Um die obigen Ausführungen zu verstehen, ist zu ergänzen,
dass die Auslieferung des Codes Klassenweise erfolgt.
Der Kunde bekommt genau die Klassen, die für ihn geändert wurden
(Oft ist dies zu einem Bereich nur eine, in der monolithisch mehrere Tausend Zeilen Code stehen).


Was ist zu beachten, wenn Vater und Kindklasse bei Bedarf separat ausgeliefert werden sollen?
D.h., beide Klassen sind evtl. schon Jahre im Einsatz und es soll eine der beiden ausgetauscht werden.
Dass sich die Schnittstellen nicht verringern dürfen, ist klar. Was gilt für Erweiterungen?
Bei welchen Änderungen der Vaterklasse muss die Kindklasse zwingend neu kompiliert werden?
 
M

maki

Gast
Hi,

in unserem Unternehmen gibt es auf hoher Ebene starke Ressentiments gegen Vererbung.
Argumentiert wird damit, dass eine Vererbung
- im Gegensatz zu einer losen Kopplung durch Methoden -
eine starke Bindung von Vater- und Kindklassen herstellt.

"bei der Vererbung gibt es eine undefinierte aber sehr starke Bindung zischen Oberklasse und erbender Klasse.
Bekannt ist in diesem Zusammenhang das Kopieren von Konstanten von der oberen Klasse in die erbende Kasse."

Aufgrunddessen sollen Änderungen an Oberklassen ohne Kentnisse der Unterklassen kaum möglich sein.
Umgekehrt ebenso. Bei einer Änderung der Oberklasse müssten auch alle Kindklassen erneut getestet werden.
klingt nach "Favour Composition over Inhertiance" und ist erstmal richtig.

Um die obigen Ausführungen zu verstehen, ist zu ergänzen,
dass die Auslieferung des Codes Klassenweise erfolgt.
Der Kunde bekommt genau die Klassen, die für ihn geändert wurden
(Oft ist dies zu einem Bereich nur eine, in der monolithisch mehrere Tausend Zeilen Code stehen).
Klingt sehr schräg..

Wie dem auch sei, sowas lässt sich mit vernünftigem Configmanagement in den Griff bekommen.

Was ist zu beachten, wenn Vater und Kindklasse bei Bedarf separat ausgeliefert werden sollen?
D.h., beide Klassen sind evtl. schon Jahre im Einsatz und es soll eine der beiden ausgetauscht werden.
Dass sich die Schnittstellen nicht verringern dürfen, ist klar. Was gilt für Erweiterungen?
Bei welchen Änderungen der Vaterklasse muss die Kindklasse zwingend neu kompiliert werden?
Bei allen Änderungen der Vaterklasse müssen die Kindklassen neu kompiliert werden.
 

langhaar!

Bekanntes Mitglied
Bei allen Änderungen der Vaterklasse müssen die Kindklassen neu kompiliert werden.

Tests von mir und Kollegen haben gezeigt, dass das nicht stimmt. :autsch:
So kann z.B. problemlos die Vaterklasse um eine neue Methode ergänzt werden und die class-Files der neuen Vater- und der alten Kindklasse arbeiten wie gewohnt zusammen.
 
S

SlaterB

Gast
das war wohl eher ein allgemeiner Hinweis/ Vorschlag als die absolute technische Klärung,
wenn du schon selber testest, wozu die Frage, hast du eine bestimmte Absicht?

man kann ja von Java-API-Klassen wie ArrayList usw. erben, letztlich muss man immer von Object erben,
und diese kompliliert man auch nicht neu..,

die grundsätzlichen Regeln dürfte doch überschaubar sein, du nennst sie selber,
Schnittstellen nicht ändern, alles was auch bei normalen Neukompilieren zweier Klassen in einem Projekt entweder zu Fehler führt oder eben in der Subklasse mitgeändert werden muss,

andersrum gibt es gar nichts, was sich auf die Super-Klasse auswirkt,
wenn man natürlich neuen Konstruktor/ Methode mit super() aufrufen will..
 
Zuletzt bearbeitet von einem Moderator:

Lowpass

Aktives Mitglied
Eine starke Meinung zum Thema Composition vs. Inheritance zu haben und gleichzeitig Klassen mit unüberschaubarem Umfang zuzlassen (mehrere tausend Zeilen Code) finde ich komplett schräg.. ebenso, .class-Files einzeln auszuliefern/auszutauschen.
Was verspricht man sich von dieser einzelnen, stückchenhaften Auslieferung?
 

langhaar!

Bekanntes Mitglied
wenn du schon selber testest, wozu die Frage, hast du eine bestimmte Absicht?
Steht oben. Ich erläuter es noch man näher. Es werden einzelne Class-Dateien ausgeliefert. Das kann ich auch nicht ändern und ist hauptsächlich dadurch begründet, dass ein validiertes Umfeld vorliegt (Pharma) und die Kunden alles, was sie bekommen, testen müssen. Da kann für eine Anpassung oder Korrektur keine Gesamtauslieferung gemacht werden.

Es gibt Kollegen, die lehnen die Vererbung grundsätzlich ab, da die Abhängigkeit von Vater und Kindklassen nicht genau definiert sei; also eine geänderte Vaterklasse nicht auslieferbar sei (ohne Vater und Kindklasse neu zu kompilieren und beide zu testen).


die grundsätzlichen Regeln dürfte doch überschaubar sein, du nennst sie selber,
Schnittstellen nicht ändern, alles was auch bei normalen Neukompilieren zweier Klassen in einem Projekt entweder zu Fehler führt oder eben in der Subklasse mitgeändert werden muss,
Wie gesagt, meine Meinung steht gegen andere und selber testen gibt Hinweise, ich hätte es aber gern genauer oder noch besser irgendwo dokumentiert.

Eine starke Meinung zum Thema Composition vs. Inheritance zu haben und gleichzeitig Klassen mit unüberschaubarem Umfang zuzlassen (mehrere tausend Zeilen Code) finde ich komplett schräg.. ebenso, .class-Files einzeln auszuliefern/auszutauschen.
Was verspricht man sich von dieser einzelnen, stückchenhaften Auslieferung?
Sollte jetzt hoffentlich ein bisschen klarer sein. Die Größe der Klassen resultiert aus den prozeduralen Programmiergewohnheiten der Entwickler...
 
Zuletzt bearbeitet:
S

SlaterB

Gast
ich weiß nicht genau ob es deine Frage betrifft,
aber neben dem technischen Teil des Kompilierens ist die inhaltliche Durchmischung ein Thema,
welches das fachliche Testen (eben über das reine Kompilieren als Syntax-Test hinaus) erfordert

wenn eine Super-Klasse in der Methode X seine Attribute anders bearbeitet als zuvor (um mal völlig vage zu bleiben..)
dann dürften die Sub-Klassen, die X verwenden und die Attribute auslesen, anders ablaufen

wie sich das schon liest hat das aber nicht unbedingt mit Vererbung zu tun, auch bei Komposition unabhängiger Klassen
tritt dasselbe auf, wenn sie sich gegenseitig nutzen,
geänderte Konstanten aus anderen Klassen sind nicht schlimmer als geerbte geänderte Konstanten,
jede Änderung im relevanten Bereich erfordert Neutesten von Allem


falls soweit schon richtige Gedanken, dann ist deine Frage womöglich,
ob speziell Vererbung statt Komposition besondere weitere Probleme macht?
hmm
 

faetzminator

Gesperrter Benutzer
Irgendwann muss man beginnen. Ich verstehe, dass es schwer und mühsam ist. Aber warum nicht einfach ab den aktuellen Änderungen Tests schreiben? Ist anfänglich vielleicht nur 1% des Codes (teste es mit EclEmma, Coverclipse o.ä.), wird aber nach und nach mehr ;)
 

faetzminator

Gesperrter Benutzer
Ich verstehe dich, aber eine andere Antwort kannst du nicht erwarten, da dies lediglich eine Symptombekämpfung ist und nicht das Problem bei der Wurzel packt... Keine Vererbung verwenden, weil die Klassen einzeln reinschneien...
 
S

SlaterB

Gast

maki hat ja 'Favour Composition over Inheritance' genannt,
wenn man dazu nachliest kommen schon paar Ideen

beim ersten Link
Favour Composition over Inheritance (FCoI) - Clean Code Developer

"Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)

-> eine Klasse könnte in einer Revision intern Attribute/ verstecktes Verhalten verändern und trotzdem nach außen unverändert bleiben,
eine erbende Klasse hat vielleicht stärkeren Zugriff auf Zwischenergebnisse statt allein public-Zustand
und ist von den Änderungen doch betroffen

-------

neues Verhalten:
eine List-Subklasse kontrolliert add(), remove() usw., lädt/ löscht entsprechende Objekte aus dem DB-Cache

nun wird in der Super-Klasse eine neue Methode clear() eingefügt, die es bisher (angenommen) nicht gab,
ohne remove() & Co. zu benutzen werden die Daten entfernt, die Sub-Klasse ist aber nicht mit geändert worden, verschläft ihre nötigen Aktionen

mit Komposition wäre das nicht möglich, dann könnte niemand an der Cache-Liste clear() aufrufen,
sofern nicht auch diese Methode unterstützt wird, an die interne richtige Liste sollte niemand rankommen
 
Zuletzt bearbeitet von einem Moderator:

langhaar!

Bekanntes Mitglied
Den Link hatte ich mir auch angesehen :)
und die Stelle 'inheritance breaks encapsulation' hat mich ins Grübeln gebracht.

Sollte meines Erachtens mit 'sauberen' Schnittstellen zu lösen sein und ist kein Grund, Vererbung komplett zu verdammen.

Werd' ich noch mal drüber meditieren.
Ich denke genau das ist die Stelle, an der es zu argumentieren gilt.

Technisch scheint es ja beim Austausch von Class-Files und Vererbung keine anderen Probleme zu geben, als bei Komposition. Dann ist zumindest der Punkt, dass die Bindung von Vater- und Kindklasse 'undefiniert' sei, hinfällig. ???:L
 
Zuletzt bearbeitet:

Aiwendil

Mitglied
Nur um mal die Sprache auf die eigentliche Frage zu bringen (nachdem wir den "warum willst du das überhaupt" und denn "aber das ist schlecht und du bist böse wenn du das so machst" Teil hoffentlich endlich hinter uns haben):

Wann du Kindklassen oft neu kompilieren musst: wenn sich statische Methoden oder statische/finale Konstanten ändern, da diese teilweise (wann genau weiß ich auch nicht) inline mit in ander Kompilate wandern.
 

langhaar!

Bekanntes Mitglied
Wann du Kindklassen oft neu kompilieren musst: wenn sich statische Methoden oder statische/finale Konstanten ändern, da diese teilweise (wann genau weiß ich auch nicht) inline mit in ander Kompilate wandern.

Mist. Genau so etwas habe ich gerüchteweise gehört (steht auch direkt schon im Eingangsbeitrag, 7. Zeile), konnte oder wollte es aber nicht so ganz glauben.
 

Ark

Top Contributor
Ich hab's gerade mal ausprobiert: Das Inlining von solchen Konstanten passiert nicht nur bei einer Vererbungsbeziehung, sondern generell. D.h., wenn eine Konstante in einer Klasse geändert wird, müssen alle Klassen, die diese Konstante benutzen, ebenfalls neu kompiliert werden.

Java:
public static final double TESTTESTTEST = Math.PI;
Code:
  // Field descriptor #6 D
  public static final double TESTTESTTEST = 3.141592653589793;
Ark
 

langhaar!

Bekanntes Mitglied
Bislang dienten die Konstanten als Argument für die undefinierte Bindung zwischen Vater- und Kindklasse.
Da dies aber genauso die Komposition betrifft, ist es kein Argument mehr, um keine Vererbung einzusetzen.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
H Zwei unabhängige Threads miteinander kommunizieren lassen Allgemeine Java-Themen 3
U Vererbung?! Allgemeine Java-Themen 15
temi Problem mit Aufrufreihenfolge bei Vererbung Allgemeine Java-Themen 3
MiMa Vererbung und Komposition?? Allgemeine Java-Themen 38
Kirby.exe Vererbung bei Generics Allgemeine Java-Themen 7
L Vererbung Verständnis Probleme Vererbung Allgemeine Java-Themen 2
W Generics + Vererbung Allgemeine Java-Themen 47
M Vererbung mithilfe von Bluej Allgemeine Java-Themen 3
M List -Tableview-Javafx-Vererbung Allgemeine Java-Themen 35
A Vererbung Selbstreferenzparameter Allgemeine Java-Themen 14
D Thema: Vererbung Ober-/Unterklassen Allgemeine Java-Themen 16
D Frage zu Vererbung Allgemeine Java-Themen 5
N Vererbung mit GUI Allgemeine Java-Themen 9
E Vererbung Countable mit Vererbung Allgemeine Java-Themen 6
J 2 Fragen zur Vererbung Allgemeine Java-Themen 5
T Javaklassen und vererbung Allgemeine Java-Themen 32
F Vererbung Allgemeine Java-Themen 5
Neumi5694 Vererbung Restriktive Vererbung Allgemeine Java-Themen 4
A Vererbung Übungsaufgabe Vererbung - Erstellung Klassenhierarchie Allgemeine Java-Themen 1
J Allgemeine Fragen zu Vererbung Allgemeine Java-Themen 1
kaoZ Generics und Vererbung Allgemeine Java-Themen 3
D Problem bei Vererbung abstrakter Klassen Allgemeine Java-Themen 6
D Object nach Vererbung mit Class Object überprüfen Allgemeine Java-Themen 4
T Super Klasse Vererbung Problem :/ Allgemeine Java-Themen 10
S MVC - Vererbung Allgemeine Java-Themen 4
C Enums und Vererbung Allgemeine Java-Themen 6
F Google Guice + Generics + Vererbung Allgemeine Java-Themen 5
D Unterschied Vererbung und Polymorphie? Allgemeine Java-Themen 4
K Vererbung ohne Basisklasse zu kennen Allgemeine Java-Themen 20
Da_Tebe ArrayList<xyz> Verschachtelung oder Vererbung? Allgemeine Java-Themen 6
faetzminator statische Variablen in Interface - Vererbung? Allgemeine Java-Themen 9
M OOP PropertyChangeListener - Vererbung oder Komposition? Allgemeine Java-Themen 5
S OOP Mehrfache Vererbung von abstrakten Klassen Allgemeine Java-Themen 7
G Designfrage Vererbung ja oder nein Allgemeine Java-Themen 9
S equals - Identität ändern bei Vererbung? Allgemeine Java-Themen 5
dayaftereh Vererbung Hilfe Allgemeine Java-Themen 2
D Vererbung, Reflection und automatischer Methodenaufruf Allgemeine Java-Themen 24
A PropertyChangeListener Vererbung Allgemeine Java-Themen 4
P DefaultTreeCellRenderer Vererbung Allgemeine Java-Themen 5
S Objekte die Objekte enthalten: Keine Vererbung Allgemeine Java-Themen 4
J Vererbung bei abstrakten Klassen Allgemeine Java-Themen 2
S Vererbung: Welche Methode wird verwendet? Allgemeine Java-Themen 9
L Checkstyle: Wann ist eine Methode für Vererbung entworfen? Allgemeine Java-Themen 13
S normale vererbung als interface Allgemeine Java-Themen 2
S statische Methoden und Vererbung Allgemeine Java-Themen 6
R Vererbung - doppelte Paint-Methode Allgemeine Java-Themen 4
R Vererbung mit Interface und Abstract Allgemeine Java-Themen 3
B Vererbung bei enums ? Allgemeine Java-Themen 3
W Frage zu Vererbung / konkretes Beispiel Allgemeine Java-Themen 4
F Vererbung von SessionBeans Allgemeine Java-Themen 3
O abstract, privat, Vererbung Allgemeine Java-Themen 29
L Annotations mit Vererbung Allgemeine Java-Themen 4
M Singleton und Vererbung? Allgemeine Java-Themen 45
T Problem mit Vererbung Allgemeine Java-Themen 3
V Vererbung und Schleifen Allgemeine Java-Themen 5
C Comparable + Vererbung Funktioniert nicht? Allgemeine Java-Themen 4
A Ansatz Objektorientierung, Methoden Vererbung Allgemeine Java-Themen 2
D Listen von Generischen Typen inkl. Vererbung Allgemeine Java-Themen 2
D Zugriffsmethode nach Vererbung ändern? Allgemeine Java-Themen 5
S Vererbung in UML Allgemeine Java-Themen 3
T Nochmal Frage zu Vererbung Interfaces etc. Allgemeine Java-Themen 10
Y Gedanken zur Vererbung Allgemeine Java-Themen 7
F Vererbung, Generizität und Collections. Allgemeine Java-Themen 7
G Frage zu statischen Variablen bei Vererbung Allgemeine Java-Themen 15
F Vererbung Allgemeine Java-Themen 5
S Vererbung von mehreren Klassen? Allgemeine Java-Themen 5
C enum und Vererbung Allgemeine Java-Themen 3
K Problem mit Vererbung - Kein wirklicher Nutzen. Allgemeine Java-Themen 10
G vererbung vs benutzung Allgemeine Java-Themen 7
L Vererbung klappt nicht Allgemeine Java-Themen 5
W Probleme mit Arrays und Vererbung ! Allgemeine Java-Themen 5
M vererbung einer "selbst-instanzierungs-klasse" Allgemeine Java-Themen 16
J Vererbung. Allgemeine Java-Themen 8
H Frage zur Vererbung Allgemeine Java-Themen 5
S private Instanzvaribalen bei "Innerer-Vererbung" Allgemeine Java-Themen 9
H Vererbung auch ohne erzeugung einer Instanz möglich? Allgemeine Java-Themen 3
M frage zur vererbung Allgemeine Java-Themen 12
G Generics und Vererbung. Allgemeine Java-Themen 21
M Vererbung von Hashtables Allgemeine Java-Themen 5
C dynamische Vererbung Allgemeine Java-Themen 6

Ähnliche Java Themen


Oben