Ich bin mir ziemlich bewusst über Builder-Muster. Auch schon mit dem Builder-Muster, das in Punkt # 2 in effektivem Java von Joshua Bloch beschrieben wird, durchgegangen.
Hier ist meine Frage - Gibt es bestimmte Vorteile, um die Builder-Klasse in der Klasse zu halten, die instanziiert?
Wir können auch die Builder-Klasse trennen und dasselbe tun.
Bitte seien Sie spezifisch mit Ihren Antworten. WIE ich bereits weiß, dass innere Klasse auf private Mitglieder der Bauklasse und all dies zugreifen kann.
Sie wissen offensichtlich bereits, dass eine geschachtelte Klasse (ob statisch oder nicht) auf private Mitglieder der umgebenden Klasse zugreifen kann.
Die wirkliche Frage ist also:
Welches Mitglied ist es wert, privat zu sein und von einem Builder darauf zuzugreifen?
Und die Antwort ist ... der Konstrukteur! Sie möchten den Konstruktor privat machen, um überhaupt keinen Zugriff zuzulassen. Sie möchten stattdessen den Zugriff auf den Builder zulassen, aber der Builder muss den Konstruktor irgendwann aufrufen, um ... nun ... ihn zu erstellen.
Wenn Sie einen Builder haben, der nicht geschachtelt ist - vielleicht eine Klasse der obersten Ebene -, müssen Sie den Konstruktor der Zielklasse mindestens package-privat machen. Und das ist normalerweise nicht erwünscht.
Fazit: Der Builder sollte eine geschachtelte Klasse sein.
Oh, und die Antwort von Davide Lorenzo MARINO ist auch wahr: Natürlich ist es auch die starke Beziehung des Erbauers und seiner umgebenden Klasse.
Erstens: Es wird als innere -Klasse definiert, da es stark mit der äußeren Klasse zusammenhängt. Von der Oracle Website :
Es ist eine Möglichkeit, Klassen logisch zu gruppieren, die nur in einem verwendet werden place : Wenn eine Klasse nur für eine andere Klasse nützlich ist, dann ist es das logisch, es in diese Klasse einzubetten und die beiden zusammen zu halten. Verschachteln Solche "Hilfsklassen" machen ihr Paket schlanker.
Zweitens: Es wird als statisch definiert, da die innere Klasse nicht statisch ist, wenn Sie sie nicht erstellen, ohne eine Instanz der äußeren Klasse zu erstellen.
Als zusätzliches nettes Verhalten können Sie den Konstruktor der äußeren Klasse private definieren. Daher ist es nicht möglich, die äußere Klasse ohne expliziten Aufruf des Builders zu erstellen.
Und mehr, wie von JB Nizet in den Kommentaren der Frage angegeben, ist es einfacher, den Builder im Javadoc zu finden, der nach der äußeren Klasse sucht.
Ich denke, es gibt zwei Gründe dafür.
the-package.Something.Builder , was selbsterklärend ist und das Paket nicht mit so vielen Klassen zusammenfasst. Nur meine zwei Cent.
Tags und Links java design-patterns