Wie sortiere ich assoziierte Klassen aus verschiedenen Projekten?

Question

Ich habe eine Situation, in der ich alten Code umstrukturiere, ein altes Monsterprojekt auseinander nehme und es (aus verschiedenen Gründen) in kleinere Teilprojekte zerlege. Ein Projekt wird meistens Schnittstellen enthalten, während die zugehörigen Implementierungen in einem anderen Projekt sind, und ich bin mir nicht sicher, wie die Paketstruktur am besten eingerichtet werden kann.

Soll ich für

org.company.interfaceproject.util.InterfaceClass und
org.company.implementationproject.util.ImplementationClass

oder

org.comp any.project.util.InterfaceClass und
org.company.project.util.ImplementationClass

wo die erste Implementierung den Vorteil, unter Hinweis darauf hat, zu denen stehen die Dateien gehören, während der zweite auf Doesn tmix in der Tatsache, dass die Dateien in verschiedenen Projekten überhaupt sind.

Ich denke, hier gibt es kein Richtig und Falsch, aber ich bin neugierig, ob jemand eine Meinung dazu hat.

Answer 1

Ja, Sie müssen nur mit einer Namenskonvention kommen. In der Regel hat eine Kombination aus beidem zu unserem Unternehmen gepasst, um Mehrdeutigkeiten zu vermeiden.Zum Beispiel, sagen Sie eine Schnittstelle hatte:

org.company.service.UserService 

Dann würden wir die folgenden für die Implementierungsklasse verwenden, die von verdrahtet wurde, oder hatte, Feder Abhängigkeiten:

org.company.service.spring.UserServiceImpl 

Dieser hat dann die beste beiden Standpunkte:

1. Sie die Klassen sauber in einem separaten Paket
2. mit dieser Klasse Namenskonvention haben, ist es klar, dass sein ein impl tion von UserService, und immer noch unterscheidbar, auch wenn beide Pakete importiert werden.

Answer 2

Beide haben Vorteile. Es hängt letztlich von Ihren Absichten für das Projekt ab. Wenn Sie beabsichtigen, alternative Implementierungen der Schnittstellen zu erstellen, ist es möglicherweise sinnvoller, mit Option 1 zu gehen. Wenn dies die einzige Implementierung der Schnittstellen ist, wäre Option 2 vernünftiger.

Answer 3

Wenn Sie können Sie die Interface-Klassen in ein separates Plugin/Paket setzen. Wenn Sie Schnittstellen verwenden, verfügen Sie meistens über mehr als eine Implementierung dieser Schnittstelle.

würde ich Option 1

Answer 4

Sun hat Naming conventions bevorzugen. Für Pakete:

Das Präfix eines einzigartigen Paketname wird in all-Klein ASCII-Buchstaben immer geschrieben und sollte einer der Top-Level-Domain-Namen, die derzeit com, edu, gov, mil, net, org sein, oder einen der englischen Zwei-Buchstaben-Codes, die Länder gemäß der ISO-Norm 3166, 1981, angeben.

Nachfolgende Komponenten des Paketnamens variieren entsprechend den internen Namenskonventionen einer Organisation. Solche Konventionen können angeben, dass bestimmte Verzeichnisnamenkomponenten Abteilungs-, Abteilungs-, Projekt-, Maschinen- oder Anmeldenamen sind.

Also würde ich die zweite Option bevorzugen, wo Sie den Projektnamen angeben. Oder ich würde beide so zusammenführen:

org.company.project.interfacepackage.util.InterfaceClass and 
org.company.project.implementationpackage.util.ImplementationClass 

Answer 5

Stimmen größtenteils mit Clinton überein.

Letztlich jeder Paketname ist eine Insel so weit wie Java betroffen ist, aber es kann sehr nützlich sein, Dinge zu trennen nach dem, was mit dem, was bei der Erstellung zusammengebaut wird, wie in:

 
com.foo.client.* 
com.foo.server.* 
com.foo.common.* 

Meist diese hält Ihre Ameisenfeilen einfach. Beachten Sie, dass dies auch dann gilt, wenn das Layout der Quelldateien aufgrund der Art und Weise, wie die Dinge erstellt werden oder was auch immer, sehr unterschiedlich ist. Das einzige, was ich sagen würde, ist vorsichtig, nicht das gleiche Paket in mehr als einem Quellverzeichnis zu bekommen! Das kann hässlich sein und ist leicht durch Zufall zu machen.

Also, wenn diese Art des Denkens treibt Sie zu separaten High-Level-Pakete zu erstellen, mag ich den Stil der Umsetzung des Pakets in das Interface-Paket, so dass das impl-Paket einen Namen, der schlägt, wie es spezialisiert ist, und der Benennung die Implementierung FooImpl. Sie müssen fast nie mehrere Implementierungen importieren, aber gelegentlich möchten Sie sowohl die Schnittstelle als auch das Impl importieren, und in diesem Fall ist es nett, wenn sie einen ähnlichen Namen haben.