Kapselung Klasse private, Konstruktor protected

[banshee]

Hallo,

welchen Sinn hat es, dass man dem Konstruktor einer privaten (statischen) Klasse einen protected bzw. überhaupt einen Modifikator voranstellt? Ist es nicht so, dass sämtliche Modifkatoren von dem private der Klassendeklaration überdeckt werden und sämtliche Konstuktoren daher sowieso nur aus derselben Klasse aufgerufen werden können?

 

[SlaterB]

im Weißen Haus kann man auch an der Besenkammer ein kleines Vorgängeschloss anbringen..,

lohnt nicht unbedingt, in solchen Fällen extra zu prüfen ob die Klasse private ist,
aber um die Frage zu beantworten: Sinn hat das keinen, denke ich

 

[hdi]

Ich finde das hat sehr wohl seinen Sinn: Wenn du eine Klasse selbst private schaltest dann ist das eine Design-Entscheidung aus Sicht der darüberliegenden Klasse. Dahingegen wenn du den Konstruktor oder irgendwelche Fields oder Methoden innerhalb einer Klasse private schaltest, dann ist das eine Design-Entscheidung dieser Klasse (nicht der darüberliegenden). Das sind zwei verschiedene Aussagen, im Hinblick auf's Design. Aus Sicht der inneren Klasse werden gewisse Dinge zB über public bereitgestellt - ob das nun eine höhere Ebene deiner Software wiederum sperrt da die gesamte Klasse in eine andere eingebettet ist, das ist was anderes, aber davon unabhängig. zB könntest du die innere Klasse später ja durchaus wieder rausnehmen und zu einer top-level Klasse machen wollen. Und dann macht's natürlich sehr wohl nen Unterschied ob jetzt zB Instanz-Variablen private sind oder nicht.

Ich würd also innere Klassen grundsätzlich so designen wie auch top-level Klassen, d.h. Konstruktoren & Getter/Setter und andere Methoden public, die Fields private. Dass es jetzt keinen Unterschied macht wenn du die ganze Klasse als inner class die private ist in eine andere reinpackst, mag stimmen. Aber wie gesagt du impliziert mit Access Modifiern immer eine Absicht.

 

[Paddelpirat]

Vielleicht, dass wenn man die Klasse nachträglich public macht, der (private) Konstruktor nicht automatisch auch allen (public) zur Verfügung steht? Wann man so etwas macht ist dann wieder eine andere Frage.

 

[bygones]

Ich würd also innere Klassen grundsätzlich so designen wie auch top-level Klassen, d.h. Konstruktoren & Getter/Setter und andere Methoden public, die Fields private

Klassen/Methoden/Konstruktoren sollen den minimal noetigsten Zugriff bekommen, nicht einfach public. Da du hier schoen von Design redest, wollte ich das dann nochmal unterstreichen.

@Topic
ich seh keinen Sinn darin einer privaten statischen Klasse einen hoehren Zugriff bei Konstruktoren/Methoden zu geben. Das Design ist so gewaehlt, dass sie als interna der aussenstehen Klassen ist, da braucht man nix nach Aussen geben.
Wenn man spaeter einmal die Klasse rausziehen will, ist das kein Problem, die Klasse war vorher reines Interna der einen Klasse, nun ist sie anderen geoeffnet....

 

[hdi]

Klassen/Methoden/Konstruktoren sollen den minimal noetigsten Zugriff bekommen, nicht einfach public. Da du hier schoen von Design redest, wollte ich das dann nochmal unterstreichen.

Ja, nicht "einfach public", das habe ich auch nicht gesagt. Ich sagte "grundsätzlich", und "grundsätzlich" ist der minimal nötigste Zugriff für sowas wie nen Konstruktor oder Getter/Setter halt public. Restriktiviere Modifier sind da eher Ausnahme.

 

[bygones]

und "grundsätzlich" ist der minimal nötigste Zugriff für sowas wie nen Konstruktor oder Getter/Setter halt public

dem widerspreche ich - solange du nicht wirkliche JavaBeans schreibst.

 

[Marco13]

Eine konsistente Anwendung der Regel: "Alles sollte so privat wie möglich sein" würde ich einem "In diesem und jenem Fall kann man (wenn man will) aber auch... " vorziehen.

 

[hdi]

Ich glaub wir sprechen aneinenander vorbei?! Mit "grundsätzlich" meinte ich nicht eine Regel, sondern wie es im Normalfall halt in der Praxis ist. Also grundsätzlich 😀 Oder wollt ihr sagen dass eure Konstruktoren und Getter in der Regel private sind? Also nochmal: Ich meinte nur eine inner class sollte aus Sicht ihrer selbst nicht anders designed werden wie eine top-level class, d.h. das, was man bei ner top-level class public machen würde, wie eben meist einen Konstruktor, sollte man in ner inner class auch public machen. Selbst wenn sie selbst dann als private in einer anderen Klasse gekapselt ist.

edit: Bei genauerer Überlegung ist das Wort "grundsätzlich" wohl falsch von mir gewählt worden. Also my bad, ich meinte nicht das wonach es klang.

 

[bygones]

Ich glaub wir sprechen aneinenander vorbei?! Mit "grundsätzlich" meinte ich nicht eine Regel, sondern wie es im Normalfall halt in der Praxis ist.

was aber nichts an der Tatsache aendert dass es falsch ist

Oder wollt ihr sagen dass eure Konstruktoren und Getter in der Regel private sind?

du weisst genug von Java um zu wissen dass es ausser private <-> public noch mehr gibt. Und unter diesem Aspekt ja, jeder Zugriff auf eine Klasse (sie selbst & Methoden) hat den geringst noetigen Modifikator.

Also nochmal: Ich meinte nur eine inner class sollte aus Sicht ihrer selbst nicht anders designed werden wie eine top-level class, d.h. das, was man bei ner top-level class public machen würde, wie eben meist einen Konstruktor, sollte man in ner inner class auch public machen. Selbst wenn sie selbst dann als private in einer anderen Klasse gekapselt ist.

eine innere Klasse steht im kompletten Kontext der top-level Klasse, daher gilt per se schon ein anderes Prinzip. Wenn man sie als top level designen will, so sollte man es auch als top level nehmen.

edit: Bei genauerer Überlegung ist das Wort "grundsätzlich" wohl falsch von mir gewählt worden. Also my bad, ich meinte nicht das wonach es klang.

;-)

 

[banshee]

Das bringt auf jeden Fall mehr Licht in die Angelegenheit 😉