Inner Class

Ich denke, dass sich dies nicht pauschal beantworten lässt.

Wenn eine Klasse nur innerhalb einer anderen Klasse benutzt werden soll / kann, dann ist es ein guter Programmierstil. Dadurch erreiche ich die Sichtbarkeit, die ich möchte.
Hier wäre ein Beispiel ein abstrakter Datentyp. Der speichert die Daten intern in Knoten oder Nodes. Aber nach außen tritt nie so eine Instanz auf....

Sobald ich etwas habe, das auch nach außen auftritt, dann ist es durchaus strittig. Das Beispiel wäre hier eine Enumeration. Die Enumeration benutzt etwas, das spezifisch für die äußere Klasse ist. Dann wird durch die Platzierung in der äußeren Klasse deutlich, dass diese genau zu dieser gehört, denn man greift dann ja OuterClass.InnerEnum.SOME_VALUE drauf zu. Macht aber wirklich nur Sinn, wenn es nur in dem Zusammenhang genutzt werden kann. Sobald ich von der OuterClass erbe sieht es schon weniger schön aus ...

Und es ist eine Katastrophe, wenn etwas hat, das auch außerhalb und unabhängig von der Klasse etwas verwenden kann ...

Und ganz nebenbei: Bei den anonymen Klassen handelt es sich streng genommen auch um inner classes. Da ist die Verwendung von außen nicht möglich, da ja anonym. Hier wäre vom Design her nur zu überlegen, ob das nicht besser geht. Da kommt man dann ggf., zu Lambda Ausdrücken und so ...
 
Java:
class OuterClass {
    
    static class NestedClass {
        //kein Zugriff auf OuterClass.this
    }
    
    class InnerClass {
        //Zugriff auf OuterClass.this
    }
    
}
 
Ich sags mal so: Wenn die Verwendung von inneren Klassen grundsätzlich schlechter Stil wäre, dann würde es sie wahrscheinlich nicht geben. Zumindest nicht in Java.
Und wie kommst du darauf, daß deren Verwendung schlechter Stil wäre?

Und es gibt durchaus Anwendungsfälle, wo innere Klassen sinnvoll sind. Wenn du innerhalb einer Klasse eine Aufgabe mit Threads lösen willst, und diese Threads ausschließlich in dieser Klasse sinnvoll zu gebrauchen sind, kann es durchaus sinnvoll sein die Threads als innere Klassen zu schreiben.

Denn einerseits ist mit der Threadklasse außerhalb der Klasse, in der sie benutzt wird, nichts anzufangen. Es ist (fast? Ich hüte mich ja gerne vor Absolutismen) nie schlechter Stil, die Sichtbarkeit von was auch immer maximal einzuschränken außer dort, wo Sichtbarkeit notwendig ist.
Im Beispiel der Threadklasse könntest du diese wenigstens package private deklarieren, dann ist sie nur innerhalb des Pakets sichtbar. Aber wozu müssen die anderen Klassen wissen können, daß es diese Klasse gibt?

Und andererseits besteht zwischen der Threadklasse und der Klasse, die sie verwendet, eine recht enge Bindung, nicht selten gehört der Code eigetlich zusammen. Nicht selten wird eine Aufgabe erstmal ohne Multithreading gelöst und wird später erst so optimiert, dann besteht die Threadklasse im Wesentlichen aus Code, der mal von der äußeren Klasse ausgeführt wurde.
Und da würde ich es als zweckmäßig ansehen, den Code beider Klassen in einer Datei zu haben.


Mal etwas ganz Grundsätzliches: Vermeide das Denken in Dogmen, denn das hat mit Denken nichts zu tun. Überlege dir lieber erst, was du erreichen willst und danach, ob dich etwas weiterbringt. Wenn jemand sagt, daß etwas grundsätzlich irgendwie sein müsse, der hat in der Regel grundsätzlich unrecht.
Viele Programmierer legen sehr viel Wert auf gut lesbaren und rasch verständlichen Programmcode. Nicht selten aus der (meist schmerzlichen) Erfahrung heraus, nach einem halben Jahr nicht mehr zu wissen was man damals eigentlich gemacht hat. Anderen ist das wiederum völlig egal.
Nun ist die Frage: Wer von beiden hat Recht?
Bei guten Leuten (oder sagen wir besser: die, die ich für gut halte) läuft so ein Streit recht schnell ins Leere weil einer von beiden sagt: Schön daß das für dich so funktioniert - ich habe aber andere Prioritäten, hier klappt das so nicht.
 
Naja, er hat nach inner class gefragt, das ist immer die innere Mitgliedsklasse...

IdR brauchst du aber nur die NestedClass...
 
//kein Zugriff auf OuterClass.this
Das Leben ist nicht immer ganz so einfach, du hast noch vergessen, dass auch der Zugriff auf den generischen Typparameter der äußeren Klasse entfällt

Deswegen sehe ich die Verwendung von NestedClasses auch als äußerst selten an

NestedClasses sind prinzipiell eigenständige Klassen, die man aus Platzgründen (und manchmal aus Gründen der Übersichtlichkeit ) mit in die Klasse stecken möchte und nicht in ein extra File
 
Ja ist etwas verwirrlich ausgedrückt 😀

Häufigkeit: normale Klassen > Nested Classes > Inner Classes
"Können": Inner Classes > normale Klassen => Nested Classes

Also Inner Classes haben den Zugriff auf die umgebene Klasse, daher können sie mehr als normale Klassen, werden aber seltener verwendet als Nested Classes, imho - weil der zusätzliche Zugriff oft nicht benötigt wird
 

Neue Themen


Zurück
Oben