Normal
Hmja, stehe im Moment vor einem ähnlichen Problem. Man hat ja "oft" packages wieapi <- Interfacesapi.impl <- Implementierungen der InterfacesUnd die scheinbar banale Frage: Wie kommt man an die Implementierungen, ohne sie public zu machen? Factories im impl-Package? Dann hat man doch wieder public-Klassen aus dem impl, dei verwendet werden können - und andere implementierungen (also aus einem api.otherimpl package) kann man nicht verwenden, womit ein Teil der Intention des Factory-Patterns ad absurdum geführt wird. Da bräuchte man sowas wie "friend" in C++... In "Practical API Design: Confessions of a Java Framework Architect" (als PDF: http://swebooks.googlecode.com/svn-history/r2/trunk/Apress.Practical.API.Design.Confessions.of.a.Java.Framework.Architect.Jul.2008.pdf ) beschreibt Jaroslav Tulach (der "Netbeans-Chef") in einem Kapitel "Allow Access Only from Friend Code" (S. 75 ff) ein paar Ansätze dazu, aber die sind recht aufwändig und nicht wirklich "schön" - da muss man wohl Prioritäten setzen...
Hmja, stehe im Moment vor einem ähnlichen Problem. Man hat ja "oft" packages wie
api <- Interfaces
api.impl <- Implementierungen der Interfaces
Und die scheinbar banale Frage: Wie kommt man an die Implementierungen, ohne sie public zu machen? Factories im impl-Package? Dann hat man doch wieder public-Klassen aus dem impl, dei verwendet werden können - und andere implementierungen (also aus einem api.otherimpl package) kann man nicht verwenden, womit ein Teil der Intention des Factory-Patterns ad absurdum geführt wird. Da bräuchte man sowas wie "friend" in C++... In "Practical API Design: Confessions of a Java Framework Architect" (als PDF: http://swebooks.googlecode.com/svn-history/r2/trunk/Apress.Practical.API.Design.Confessions.of.a.Java.Framework.Architect.Jul.2008.pdf ) beschreibt Jaroslav Tulach (der "Netbeans-Chef") in einem Kapitel "Allow Access Only from Friend Code" (S. 75 ff) ein paar Ansätze dazu, aber die sind recht aufwändig und nicht wirklich "schön" - da muss man wohl Prioritäten setzen...
