OOP Aufruf von Methoden höherer Sichtbarkeit

[cmrudolph]

Hi,

ich habe gerade in einem Buch gelesen, dass eine Methode niemals andere Methoden höherer Sichtbarkeit aufrufen sollte.

Zum einen finde ich diese Aussage viel zu allgemein, denn dann könnte ja kein vollständig gekapseltes Objekt (beispielsweise eine Registry in einem DataMapper) benutzt werden, da dessen Interface naturgemäß öffentlich ist.

Desweiteren habe ich in einem anderen Buch (ist länger her und ich weiß nicht mehr genau welches es war) eine schlüssige Argumentation gelesen, weshalb man nach Möglichkeit immer auf Methoden höherer Sichtbarkeit zugreifen sollte: Es ist ja so, dass sich eine öffentliche Methode so selten wie möglich ändern sollte, weil man die Auswirkungen einer Änderung nicht unter Kontrolle hat, da jeder die Methode nutzen kann. Wie sie intern arbeitet und welche Strukturen sie benutzt ist dabei erstmal egal. Je geringer jedoch die Sichtbarkeit ist, desto eher kann man Methoden auch einmal entfernen oder deren Signatur ändern. Es ist also sinnvoll beispielsweise auch in der Klasse ein Attribut mit dem Getter zu lesen und dem Setter zu setzen, anstatt immer direkt darauf zuzugreifen, weil im Setter beispielsweise auch die Gültigkeit geprüft wird. Außerdem erspart man sich Refakturierungsarbeit, wenn sich die interne Struktur der Klasse ändert - man also beispielsweise eine andere Datenstruktur zum speichern von Daten verwendet.

Diese beiden Aussagen stehen im Widerspruch zueinander und ich kann die erste ehrlich gesagt nicht nachvollziehen. Welche Argumente sprechen dafür?

Viele Grüße
Christian

 

[SlaterB]

es gibt bei Sichtbarkeiten keine geographische Anordnung nach Höhenstufen, insofern ist schon unklar was genau gemeint ist,
ist private höher oder tiefer als protected?

wirre Aussagen aufzustellen kann auch jeder 'ein getter darf man nur mit einem t schreiben',
so ist das jetzt hier auch mit Argumenten für und wider zu diskutieren? 😉

Sichtbarkeiten haben eine fundierte Grundlage um Aufrufe etwas einzuschränken,
wer von wo welche Sichtbarkeit aufrufen kann ergibt sich aus den Regeln, was ist dann noch offen?
was man wo einsetzen sollte ist sicher ein Thema, aber technisch ist die Funktionalität doch ohne Rätsel

edit:
oh, ich habe
'dass eine Methode niemals andere Methoden höherer Sichtbarkeit aufrufen kann.'
statt
'dass eine Methode niemals andere Methoden höherer Sichtbarkeit aufrufen sollte.'
gelesen, schade, umsonst gemeckert

 

[maki]

ich habe gerade in einem Buch gelesen, dass eine Methode niemals andere Methoden höherer Sichtbarkeit aufrufen sollte.

Kling nicht richtig.
Um welches Buch geht es denn?

 

[cmrudolph]

es gibt bei Sichtbarkeiten keine geographische Anordnung nach Höhenstufen, insofern ist schon unklar was genau gemeint ist,
ist private höher oder tiefer als protected?

Was vom Autor als höher und niedriger deklariert wurde, habe ich hier weggelassen, da ich diese Definition plausibel fand: je höher die sichtbarkeit, desto mehr Objekte können sie verwenden. Eine private Methode ist also weniger sichtbar als eine öffentliche.

Sichtbarkeiten haben eine fundierte Grundlage um Aufrufe etwas einzuschränken,
wer von wo welche Sichtbarkeit aufrufen kann ergibt sich aus den Regeln, was ist dann noch offen?
was man wo einsetzen sollte ist sicher ein Thema, aber technisch ist die Funktionalität doch ohne Rätsel

Die Funktionalität ist klar. Es geht genau darum, wie man seinen Code wartbar hält und die Möglichkeiten nutzt, die einem erlaubt sind. Ich denke mein obiges Beispiel mit dem Setter veranschaulicht es schon ganz gut: es gibt zwei Möglichkeiten:

1. ich greife direkt auf das private Feld zu
2. ich verwende den Setter um das Feld zu ändern

Edit:

Um welches Buch geht es denn?

Der Weg zum Java-Profi von Michael Inden.
Edit2: S. 35 der Tipp, im korrigierten Nachdruck der ersten Auflage.

 

[Spacerat]

ich habe gerade in einem Buch gelesen, dass eine Methode niemals andere Methoden höherer Sichtbarkeit aufrufen sollte.

Da würde ich aber fluchs noch mal nach lesen, denn stimmen kann das nicht. Höhere Sichtbarkeit bedeutet wohl mehr Zugriffsrechte, das heisst public ist wohl am sichtbarsten. Das ich auf protected und private nicht immer Zugriff habe, ist klar. Aber was mache ich denn in einer private-Methode, wenn du dich nicht verlesen hast? Etwa keine einzige Methode mehr aufrufen?
[EDIT]Leseprobe mit besagter Stelle gefunden: http://www.dpunkt.de/leseproben/3314/4_Objektorientiertes Design.pdf
...und er hat sich nicht verlesen. Aber hey... das's Blödsinn, oder was? 😉[/EDIT]

 

[tfa]

Aber was mache ich denn in einer private-Methode, wenn du dich nicht verlesen hast? Etwa keine einzige Methode mehr aufrufen?

Nein. Weitere private Methoden aufrufen.

 

[cmrudolph]

Aber was mache ich denn in einer private-Methode, wenn du dich nicht verlesen hast? Etwa keine einzige Methode mehr aufrufen?

Keine einzige Methode mehr ist ja nicht ganz richtig. Wahrscheinlich hat die Klasse weitere private Methoden. Siehe auch meine Argumentation im ersten Posting, dort habe ich das Beispiel einer eingebetteten Registry genannt.

Mich wundert es nur, dass in einem Buch, das hier im Forum empfohlen wird und das auch bei Amazon derartig gute Rezensionen bekommen hat, so ein Pauschaltipp steht, der meines Erachtens nach falsch ist.

 

[fifo]

In den o.g. Buch heiß es vorher:

Um den Sourcecode übersichtlich zuhalten, sollten sich öffentliche Methoden aus Methodenaufrufen anderer Sichtbarkeiten zusammensetzen und wenig Implementierungsdetails zeigen. Zudem sollten Methoden niemals andere Methoden höherer Sichtbarkeit aufrufen; eine private Methode "darf" demnach keine öffentliche Methode aufrufen.

Ich verstehe das jetzt so, dass eine öffentliche Methode "nur" eine oder mehrere private Methoden aufrufen sollte. Die eigentliche Implementierung in einer privaten Methode stehen soll. Daraus würde sich ergeben, dass eine öffentliche immer zu einer privaten Methode weiterleitet. Der Grund für diesen Tipp erschießt sich mir im Moment aber auch nicht.

 

[bone2]

equals() und toString() sind public oder? das machts schwierig...

aber ist das vielleicht nur innerhalb einer klasse gemeint? wo man der übersichtlichkeit halber oft mehre private methoden in einer public verwendet, um die einzelne methode nicht zu lang werden zu lassen.

 

[Spacerat]

Ich verstehe das jetzt so, dass eine öffentliche Methode "nur" eine oder mehrere private Methoden aufrufen sollte. Die eigentliche Implementierung in einer privaten Methode stehen soll. Daraus würde sich ergeben, dass eine öffentliche immer zu einer privaten Methode weiterleitet. Der Grund für diesen Tipp erschießt sich mir im Moment aber auch nicht.

Der Grund dafür wird dir vllt. klarer, wenn du dir z.B. mal die "Unfälle" im Quelltext der Component-Klasse aus dem AWT-Api anschaust. Versuch' mal vernünftig (also ohne @Deprecated) z.B. die "setBounds()"-Methode zu überschreiben, in deiner Klasse als final zu markieren während du deine Klasse aber erweiterbar lässt. Der nächste, der sie erweitert, kommt vllt. auf den Gedanken und überschreibt "reshape()" und sch... dir mit deinem "final" auf den Kopf. Hätte man aus "setBounds()" heraus gleich eine Methode aufgerufen, die nicht erst noch wieder durch 'ne andere überschreibbare Methode geht, hätte man diesen Ärger nicht.
Wenn ich aber aus einer privaten Methode eine sichtbarere aufrufe, sorge ich unter Umständen dafür, dass diese öffentliche Methode vernünftig überschrieben werden muss, weil in der privaten sonst 'ne Exception fliegt.
Ausserdem... aus welcher Art Methode werden eigentlich vorwiegend öffentliche abstrakte Methoden aufgerufen? Aus private bzw. protected Methoden, oder seh' ich das falsch?
Von daher... in die Richtung von public nach private macht der Tip durchaus Sinn, aber in die andere Richtung halt nicht.

 

[maki]

Um den Sourcecode übersichtlich zuhalten, sollten sich öffentliche Methoden aus Methodenaufrufen anderer Sichtbarkeiten zusammensetzen und wenig Implementierungsdetails zeigen.

Das sehe ich so genauso.

Aber das private Methoden keine public Methoden aufrufen dürfen... hmmm... da fallen mir auch ein paar Ausnahmen ein...