Verständnis zur Strukturierung von Java-Projekten/Interfaces

[Chrstina666]

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

 

[Wildcard]

Soetwas würde man zB bei einer Client Server Architektur vorfinden. Der Client muss mit dem Server kommunizieren (daher die Abhängigkeit auf die Interfaces), muss aber natürlich nicht den Server selbst als Bibliothek mitführen.
Man trennt damit ganz einfach die öffentliche Schnittstelle (API) von der Implementierung.

 

[byte]

zu 1.) Das kommt drauf an. Wenn Du eine Client / Server Anwendung schreibst, dann hast Du z.B. Service Interfaces, die sowohl Client als auch Server kennen. Aber nur der Server implementiert diese Interfaces. In diesem Fall ist es sinnvoll, diese Interfaces ohne die Implementierungen in ein Projekt auszulagern, so dass der Client am Ende nur die Interfaces kennt und nur der Server die Implementierung.
Anders siehts aber z.B. bei Business Objekten aus, die zwischen dem Client und Server ausgetauscht werden. Wenn der Client über einen Service bestimmte Objekte anfordert und der Server diese Objekte an den Client liefert, dann reicht es nicht, wenn der Client die Interfaces dieser Objekte kennt. Er muss auch die Implementierungen kennen, damit der ClassLoader auf dem Client sie laden kann.
Nun kommt es auf die eingesetzte RPC-Implementierung an. RMI kennt z.B. Dynamic Class Loading, dabei kann man eine Codebase auf dem Server definieren, von dem der Client die Klassen "runterladen" kann. In diesem Fall würde es reichen, wenn er die Interfaces kennt. Beim Httpinvoker von Spring hingegen geht das aber z.B. nicht. Da muss auch der Client die Implementierung kennen.

zu 2.) Die Factories gehören zur Implementierung der Interfaces, im Idealfall ins gleiche Package, so dass man die Konstruktoren Package-Private machen kann.