Sichtbarkeit von Klassen und gute Architektur

[Usul]

Hallo,

ich habe Erfahrung mit C# und dort gibt es den praktischen modifier internal für Klassen. Wenn eine Klasse diesen Modifier besitzt, so ist sie innerhalb des Assemblies (ein Assembly entspricht einer JAR oder einer DLL) public aber nicht von aussen sichtbar (also Code, welcher dieses Assembly importiert kann diese Klasse nicht sehen). Bei Java gibt es das ja nicht, hier gibts nur entweder alle oder nur ein einzelnes package.

Wie kann man damit aber nun schöne Bibliotheken erstellen? Angenommen ich schreibe Code, welcher später von anderen Java-Projekten genutzt werden soll. Diese sollen aber nur die öffentlichen Klassen (oder Interfaces) sehen, was ja gutes Design ist. Allerdings möchte ich meinen Code ja schon in verschiedenen Packages struktieren und nicht alles in ein Package quetschen, da das schlechtes Design ist. In C# ist dies kein Problem aber in Java scheinen diese beiden Anforderungen sich zu beissen. Wie ist hier die Standard-Vorgehensweise?

Beispiel:
package foo: AClass, SomeFacade
package bar BClass

SomeFacade soll jetzt nach aussen sichtbar sein und ist somit public (das ist ja kein Problem). AClass und BClass sollen jedoch nicht sichtbar sein, aber AClass soll BClass kennen. In Java nicht möglich.


Vielen Dan

 

[MQue]

Generell sollte man Module/Komponenten/Bundles mit hoher Kohäsion und looser Kopplung programmieren -> dein Design wiederspricht dem.
Alles was zusammen gehört, sollte man in einem Modul bündeln dann hat man eine hohe Kohösion.
Aber du hast recht, dass ist mir auch unbekannt, wie man das machen kann, ohne dass ein weiteres Interface nach außen sichtbar ist -> aber wie geasgt, das Design so wählen, dass das gar nicht notwendig ist.
In OSGi ist es z.B.: üblich, dass man ein package für die Implementierung hat und ein Package, in dem man die Schnittstellen (Interfaces) für dieses Package bereitstellt und die Implementierungs- Packages haben untereinander nichts miteinander zu tun -> das ist ein Standard von OSGi

 

[Wildcard]

OSGi ist das richtige Stichwort. Statte deine Bibliothek mit einem OSGi Manifest aus, dort ist explizit vermerkt welche Packages öffentlich sind und welche nicht.
In einer IDE werden diese Informationen zur Compilezeit auch ausgewertet und in einem OSGi Framework zur Laufzeit. Bei Plain Java Projekten ohne passende IDE hast du deine intentionen dann wenigstens im Manifest klargemacht, wer sich nicht daran hält braucht sich später nicht zu wundern wenn der non-public Teil nicht abwärtskompatibel ist.
Generell würde ich empfehlen jede Art von Library mit OSGi kompatiblem Manifest auszuliefern

 

[Usul]

Generell sollte man Module/Komponenten/Bundles mit hoher Kohäsion und looser Kopplung programmieren -> dein Design wiederspricht dem.
Alles was zusammen gehört, sollte man in einem Modul bündeln dann hat man eine hohe Kohösion.
Aber du hast recht, dass ist mir auch unbekannt, wie man das machen kann, ohne dass ein weiteres Interface nach außen sichtbar ist -> aber wie geasgt, das Design so wählen, dass das gar nicht notwendig ist.
In OSGi ist es z.B.: üblich, dass man ein package für die Implementierung hat und ein Package, in dem man die Schnittstellen (Interfaces) für dieses Package bereitstellt und die Implementierungs- Packages haben untereinander nichts miteinander zu tun -> das ist ein Standard von OSGi

Mir ist das Prinzip mit high cohesion low coupling bekannt und auch OSGi kenne ich. Aber Module haben nichts mit packages zu tun. Ein Modul/Komponente ist nicht ein package. Packages sollten der Strukturierung dienen. Alles in eine Art Gott-package zu packen ist wie wenn man auf Klassen-Ebene eine Gott-Klasse hat. Ein Modul sollte intern in mehrere packages strukturierbar sein, ohne dass damit gleich alles extern öffentlich ist.

Letztendlich hat man durch OOP gelernt, dass Kapselung sinnvoll ist. Nun muss man dieses Prinzip von der Klassen-Ebene auch auf die "Modul" (JAR)-Ebene übertragen.

Und ja mit OSGi ist das natürlich möglich. Allerdings ist die Bibliothek dann vom Framework abhängig. Man hat somit ein OSGi-Plugin welches nur mit OSGi funktioniert. Das würde ich aber gerne vermeiden.

Ich habe allerdings Hoffnung auf Java 1.7. Denn wie es aussieht ist man sich dem Problem bewusst und es wird ein Konzept namens Superpackages engeführt (Super Packages in Java 7.0). Das ist im Prinzip genau das für Java, was bis jetzt nur mit Frameworks wie OSGi möglich ist.

 

[maki]

Aber Module haben nichts mit packages zu tun.

Doch natürlich, zB: Modul A braucht Package a.b.c
Wenn man Module von Modulen abhängig macht, ist man gar nicht so flexibel, packages sind da eine bessere weil flexiblere Lösung -> Module müssen sich nicht gegenseitig kennen

Ein Modul sollte intern in mehrere packages strukturierbar sein, ohne dass damit gleich alles extern öffentlich ist.

Genau das bietet OSGi.

Letztendlich hat man durch OOP gelernt, dass Kapselung sinnvoll ist. Nun muss man dieses Prinzip von der Klassen-Ebene auch auf die "Modul" (JAR)-Ebene übertragen.

s.o., genau das bietet OSGi

Und ja mit OSGi ist das natürlich möglich. Allerdings ist die Bibliothek dann vom Framework abhängig. Man hat somit ein OSGi-Plugin welches nur mit OSGi funktioniert. Das würde ich aber gerne vermeiden.

Siehe Wildcards post, solange du keine OSGi API benutzt läuft deine Jar auch ohne OSGi Plattform.

Ich habe allerdings Hoffnung auf Java 1.7. Denn wie es aussieht ist man sich dem Problem bewusst und es wird ein Konzept namens Superpackages engeführt (Super Packages in Java 7.0). Das ist im Prinzip genau das für Java, was bis jetzt nur mit Frameworks wie OSGi möglich ist.

IMHO ist das kommende Java Modul System leider nur ein verstümmelter Abklatsch eines echten Modulsystems wie OSGi...

 

[Wildcard]

IMHO ist das kommende Java Modul System leider nur ein verstümmelter Abklatsch eines echten Modulsystems wie OSGi...

Absolut. Hoffentlich wird JSR294 rechtzeitig beerdigt bevor jemand auf die Idee kommt es zu benutzen.
AlBlue's Weblog: JSR294 Fantasy Version Series - Roman Numerals