Ist es eine gute Übung, Methoden mit einer höheren Sichtbarkeit zu überschreiben?
Beantworten Sie diese Frage: Wie man GUI - Mit Hilfe von paintcomponent () eine GUI initialisieren und dann eine GUI basierend auf der Maus hinzufügen kann Ich habe dies gesagt:
Sie überschreiben
paintComponent()nicht richtig. Dies ist geschützt Methode, nicht öffentlich. Wenn Sie@OverrideAnnotation für diese Methode hinzufügen dann wird der Compiler beschweren.
Aber @peeskillet wies weise darauf hin:
Der Compiler wird sich nicht über
publicoderprotectedbeschweren %Code%. Sie können mit höherer Sichtbarkeit überschreiben, aber nicht mit a niedriger.paintComponentist höher alspublic, also gibt es kein Problem.
Was sicherlich stimmt. Aber jetzt stellt sich diese Frage: Ist es gute Übung, mit einer höheren Sichtbarkeit zu überschreiben?
Nachtrag
Verknüpfen Sie mit JComponent.paintComponent () javadoc.
Bild von Netbeans, die sich überhaupt nicht beschweren:
8 Antworten
Ein Grund dafür ist, wenn Sie eine Methode haben, die Sie an anderer Stelle in Ihrem Projekt überschreiben müssen, und der aktuelle Bereich dies nicht zulässt. In der Regel bei Verwendung von Standard anstelle von geschützt.
Durch Erstellen einer neuen Unterklasse im richtigen Paket an einem anderen Ort in Ihrem Projekt mit überarbeitetem Bereich können Sie dann eine anonyme Klasse in Ihrem Code erstellen, an der Sie sie benötigen, da Sie jetzt die problematische Methode überschreiben können mit Reflektion (was für ziemlich unlesbaren Code sorgt).
Dies ist auch ein Grund dafür, dass Bibliotheksklassen niemals endgültig sind, denn dann können Sie solche Dinge nicht tun.
BEARBEITEN: Ich wurde gefragt, warum das für Dependency Injection relevant ist. Ich kann nur basierend auf meinen eigenen Erfahrungen sprechen, zuerst mit Guice und jetzt mit Dagger.
Dagger verwendet Constructor Injection, was im Grunde bedeutet, dass eine Klasse alle Abhängigkeiten erhält, die dem Konstruktor (und nur dort) als Argumente zur Verfügung gestellt werden und dass der zusammen bindende Klebecode in einem Dagger @Module aufgelistet ist. In diesem Modul ist es normalerweise sehr praktisch, eine Unterklasse einer Bibliotheksklasse zurückzugeben, die mit Protokollanweisungen erweitert oder eine benutzerdefinierte toString () -Methode bereitstellt. Um dies ohne Reflektions-Tricks tatsächlich zu tun, kann die Klasse nicht endgültig sein und Sie müssen in der Lage sein, Methoden außer Kraft zu setzen und Felder in der Oberklasse direkt zu verwenden. Daher müssen keine endgültigen Klassen und beide Typen mindestens protected statt private sein!
(und ich kann die Verwendung von Dagger dringend empfehlen, da es die im java Compiler auflösende Abhängigkeit verschiebt und der IDE die Informationen gibt, die benötigt werden, um Probleme bei der Kompilierung zu lösen, anstatt von Magie in der Laufzeit in der Wildnis abhängig zu sein immer noch erstaunt über den Einblick in das Java-Ökosystem, mussten die Dagger-Designer diese Idee sogar bekommen und dann realisieren.
Aus dem Java-Lernprogramm Zugriff auf Mitglieder einer Klasse steuern :
Wenn andere Programmierer Ihre Klasse verwenden, möchten Sie diese Fehler sicherstellen vor Missbrauch kann nicht passieren. Zugriffsebenen können Ihnen dabei helfen.
- Verwenden Sie die restriktivste Zugriffsebene , die für ein bestimmtes Mitglied sinnvoll ist. Verwenden Sie privat, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.
- Vermeiden Sie öffentliche Felder mit Ausnahme von Konstanten. (Viele der Beispiele im Tutorial verwenden öffentliche Felder. Dies kann helfen, einige
zu veranschaulichen weist prägnant darauf hin, wird aber für den Produktionscode nicht empfohlen.) Öffentlich Felder neigen dazu, Sie mit einer bestimmten Implementierung zu verknüpfen und Ihre Flexibilität bei der Änderung Ihres Codes.
Dieser Ratschlag zielt darauf ab, die Kopplung zu reduzieren :
Um die beste Kapselung zu erreichen (Information Hiding) sollten Sie deklariere immer Methoden mit der geringsten Sichtbarkeit, die funktioniert . In kleinen Programme gibt es wirklich kein Problem, aber in großen Programmen dieses Problem übermäßige Kopplung ist sehr ernst. Die Kopplung erfolgt bei einem Teil hängt von der spezifischen Implementierung eines anderen ab. Je mehr Kopplung Je teurer es ist, Änderungen zu machen, desto zu viel Der Code hängt von bestimmten Implementierungen ab. Dies verursacht Softwarefehler Programm wird zunehmend weniger nutzbar, weil es nicht leicht sein kann aktualisiert.
Eine zunehmende Sichtbarkeit ist also eigentlich keine gute Idee. Ein solcher Code könnte Probleme bei der zukünftigen Entwicklung und Wartung verursachen.
Wenn Sie von außerhalb der Klasse / Unterklasse, auf der sie sich befindet, auf die Methode zugreifen müssen, besteht eine Lösung darin, die Sichtbarkeit mit dem Parameter public zu überschreiben. Es empfiehlt sich, Ihre Variablen und Methoden auf die niedrigste Sichtbarkeit zu setzen.
Sie können die Sichtbarkeit einer Methode verbessern, um sichtbarer, aber nicht weniger sichtbar zu werden, und so kann paintComponent überschrieben und als public -Methode deklariert werden. Nachdem ich das gesagt habe, füge ich hinzu, dass Sie das nicht tun sollten. Wenn Sie die Methode überschreiben, sollten Sie stattdessen die Sichtbarkeit unverändert lassen, es sei denn, Sie haben einen sehr guten Grund, sie sichtbarer zu machen.
Aus Sicht der OOP gibt es kein Problem damit. Durch das Erweitern einer Klasse können Sie folgende Dinge tun:
- Ändern Sie einige der Funktionen (durch Überschreiben einer Methode)
- Erweitern Sie die Schnittstelle der Klasse (indem Sie eine neue öffentliche Methode hinzufügen)
Wenn Sie eine Methode überschreiben und ihre Sichtbarkeit ändern, tun Sie beides: Sie - offensichtlich - ändern Sie die Funktionalität, sondern erweitern Sie auch die Schnittstelle. Aus Sicht des Clients erstellen Sie in der Klasse eine neue Methode. Diese neue Methode hat zufälligerweise den gleichen Namen wie eine interne Methode in der Oberklasse, aber der Client kümmert sich nicht (oder weiß nicht einmal darüber). Also warum solltest du nicht?
Auf der anderen Seite steht die Frage "Warum müssen Sie das tun?". Der Autor der Oberklasse hatte wahrscheinlich einige Gedanken über die Sichtbarkeit dieser Methode und stellte fest, dass seine Funktionalität nicht für die Außenwelt bestimmt ist. Ich meine nicht, dass es falsch ist, aber du musst deine Motive in Frage stellen, um die Sichtbarkeit zu erhöhen, weil es ein Hinweis auf wahrscheinlich schlechtes Design in deinem oder dem Code der Oberklasse sein könnte.
Btw: Wie bereits erwähnt, hier die Verwendung dieser Sprachfunktion kann sogar schädlich sein.
Überschriebene Methoden sollten wie alle anderen Methoden nur dann als public deklariert werden, wenn Sie möchten, dass externer Code sie aufrufen kann (außer Sie haben keine Wahl, da die überschriebene Methode als public deklariert wird). In Ihrem Fall sollte die überschriebene Methode paintComponent nur von Swing aufgerufen werden, also bleibt protected die beste Option.
Um dem hinzuzufügen, was Francois gesagt hat, ist das OOP-Prinzip hier das " Open Close-Prinzip , "die besagt, dass Sie ein Objekt erweitern, aber nicht ändern können. "Die Sichtbarkeit einer Methode zu erhöhen, indem man sie außer Kraft setzt, ist einfach eine Erweiterung, wie Francois darauf hingewiesen hat.
Es gibt viele Argumente, um die Sichtbarkeit zu ändern. Aber denken Sie nur daran, dass Sie die Schnittstelle (im Sinne von API) dieser Klasse ändern würden. Lesen Sie sich entwickelnde APIs und verknüpfen Sie diese Informationen mit Ihrer Frage.
Also wäre es in meinem Buch eine gute Übung, die Sichtbarkeit nicht zu verändern - wenn irgend möglich. Sonst müssen Sie die Konsequenzen sorgfältig abwägen - wenn auch nur auf lange Sicht.
Tags und Links java override class-design