Strukturfrage: Interfaces und Factories in JARs

[Björn Karpenstein]

Hallo!

Ich habe jetzt einige Zeit in einem größerem JAVA-Projekt mitgearbeitet, ohne architektonisch aktiv zu werden, welches sich durch folgende Eigenschaften ausgezeichnet hat:

=) Spring Framework - Es wurde viel mit Dependency Injection gearbeitet
=) BUILD Tool Maven
==) Viele eigene Projekte innerhalb Eclipse
===) Viele Projekte beinhalten ausschließlich Interfaces
====) Diese Projekte wurden als Abhängigkeit in anderen Projekten beim BUILD festgelegt

Jetzt habe ich mal generell eine Frage zu dieser Vorgehensweise.

Ich habe 2 Seiten.
Die erste Seite ist das Projekt, was die JAR-Datei verwenden möchte
Die zweite Seite ist die JAR-Datei selbst, die vom Projekt verwendet wird.

1.) Ab wann erstellt man eigenständige JAR-Archive die ausschließlich Interfaces ohne Implementierung beinhalten?
1.1.) Wenn man dies tut, wird dann die Implementierung in ein drittes Projekt zwangsläufig ausgelagert?

2.) Auf welcher Seite sind Factories, die eine Instanz "durch" eine Interfacevariable zurückliefern? Sind die auf der Seite vom JAR-Archiv, oder in dem Projekt, in dem sie verwendet werden?

Viele Grüße,
Björn

 

[Oliver Gierke]

Ich hoffe, ich verstehe richtig was du meinst. Ich versuchs mal folgendermaßen.

Im Normalfall zerlegt man Softwaresystem logisch so, dass es Subsysteme gibt, die Funktionalität anbieten und Subsysteme, die Funnktionalität konsumieren. Die nennt man dann auch oft Server (Anbieter) und Client (Konsumierer), auch wenn es da nicht unbedingt eine physische Verteilung geben muss. Eher, um die Rollen zu verdeutlichen.

Zwischen den Beiden gibt es jetzt ein logisches Interface (dass sich durch mehrere Javainterfaces, Klassen und Exceptions auszeichnen kann. Diese 3 Teile packt man nun oft in 3 verschiedene Jars (Eclipseprojekte, Mavenmodule), einfach, um die Abhängigkeiten zwischen ihnen restriktieren zu können. Der Client darf nur auf das Interface zugreifen, der Server implementiert das Interface, hat aber keine Abhängigkeit zum Client.

Unter Umständen hat man jedoch auch verschiedene Clients für den gleichen Server (Swinggui und Webanwendung). Die Trennung in die physischen Jars bringt nun den Vorteil, dass du beim Deployment des Clients nur das Interface Jar benötigst, nicht jedoch das Server Jar. Umgedreht genauso.

Wie kommt man aber nun zu einem gesamten System aus der Ansammlung von Jars? Vielleicht noch einen kurzen Schritt zurück: wenn du bereits mit Spring arbeitest ist dir sicherlich folgendes Vorgehen vertraut. Du legst dir Jars in den Classpath und konfigurierst dir Instanzen davon zu einem System - eine Hibernate SessionFactory z.B. Genauso tust du das nun für deine fachlichen Jars. Du hast also ein 4. Projekt, das genau die JARs bekommt, die es benötigt und die erforderlichen Beziehungen herstellt. Du erzeugst darin z.B. per XMl Konfiguration eine Instanz der Serverimplementierung, die ein Interface aus dem Interface Jar implementiert. Desweiteren erzeugst du eine Instanz des Clients und reichst ihm die Serverinstanz herein.

Sorry, wenn ich zu weit ausgeholt hab, aber sowas ist immer recht schwierig, wenn man nicht weiß was der Fragesteller für Vorkenntisse hat. Ich bin mir sicher es gibt Rückfragen

Hier ist noch ein wenig Beispielcode aus einem Vortrag zu Spring, den ich mal gehalten hab. Der verdeutlicht die Aufteilung ziemlich gut, wie ich finde.

Gruß
Ollie