Die fragile Basisklasse ist einer der häufigsten Punkte, der in jeder Diskussion auftaucht, wenn die Wiederverwendbarkeit durch Implementierungsvererbung diskutiert wird.
Hat jemand mit diesen Problemen zu tun gehabt, abgesehen von den üblichen quadratischen Beispielen?
Jedes Mal, wenn ich jemandem das erklären muss, stecke ich in einigen Fällen, in denen diese Probleme auftraten und wie das gelöst wurde.
Wenn jemand seine diesbezüglichen Erfahrungen teilen möchte, wäre das sehr hilfreich.
Hier ist ein Wikipedia-Link, um dieses Problem zu verstehen.
Zerbrechliche Basisklasse in Wikipedia
Meine Eingaben dazu ... Das Problem tritt meist auf, wenn sich die Basisklassenversion ändert, da die Entwickler, die diese verwenden, die Erweiterungen der Basisklassenimplementierung möglicherweise nicht kennen und das Basisklassenimplementierer möglicherweise nicht alle erforderlichen Details zu allen abgeleiteten Klassen besitzt. Und die scheinbar harmlose Änderung kann alle abgeleiteten Klassenfunktionen zerstören. Und in jedem Fall ist dies eine schlechte Design-Praxis, da es das OCP-Prinzip brechen wird.
Ja - java.util.Properties ist ein Schmerz, von dem man ableiten kann.
Im Moment lassen wir die Tatsache unberücksichtigt, dass sie von java.util.Hashtable herrührt (was bedeutet, dass sie get(Object) und put(Object, Object) hat, obwohl Eigenschaften immer Zeichenketten sind ...
Ich habe java.util.Properties einmal in Unterklassen unterteilt, um eine Art hierarchische Struktur zu erhalten - in einer Eigenschaftendatei hatte ich:
%Vor%und Sie könnten die "Master" -Eigenschaften für "x" (mit einem neuen Methodenaufruf) fragen und es würde Ihnen ein anderes Eigenschaftenobjekt geben, das effektiv "yz = 10" usw. enthalten würde. Es war praktisch, java.util zu unterklassieren Eigenschaften wie viele andere Code-Stücke kannten bereits verwendete Eigenschaften. Wenn es eine Schnittstelle implementiert hätte, hätte ich nicht unterklassifiziert, und ich hätte keine Probleme gehabt: (
Wie auch immer, ich musste getProperty () überschreiben, um bei Bedarf auf die übergeordneten Eigenschaften zurückzukommen. Aber es gibt zwei Überladungen - welche sollte ich übersteuern? Ruft getProperty (String) getProperty (String, String) auf oder umgekehrt? Vielleicht muss ich nur get () übersteuern? Es ist nicht dokumentiert, und wenn ich nur eines von ihnen überschreibe, könnte sich die Implementierung in einer späteren Version ändern, um die Dinge umzuschalten - also musste ich beide überschreiben.
Dasselbe galt für verschiedene andere Methoden (Speichern und Laden war ein Schmerz, IIRC - das war lange her). Grundsätzlich hätte ich den Job einfacher machen können, wenn ich mich darauf verlassen hätte, dass Teile der Implementierung von Eigenschaften sich nicht ändern würden - aber das hätte es offensichtlich für Sun erschwert, die Implementierung zu einem späteren Zeitpunkt zu verbessern.
Wie auch immer, dies war ein definitives Beispiel, bei dem die Zusammensetzung und das Aufzeigen einer Schnittstelle, auf die sich die Kunden verlassen würden, viel besser gewesen wäre.
Tags und Links inheritance oop