Paket-für-Schicht-VS-Paket-nach-Merkmal-Bibliotheksbenennung?

Question

Ich weiß, dass dies mehrere verbundene Beiträge hat, aber ich habe einige spezifische Fragen, auf die ich hoffe, dass ich Hilfe bekommen kann. Sorry, wenn sie sehr einfach sind ..

Hier ist ein Beispielproblem - sehr vereinfacht, aber Sie bekommen das Bild - Ich habe mehrere Objekte, die eine gemeinsame Funktion haben, z. Abteilungen in einem pharmazeutischen Unternehmen - Neurologie, Onkologie, Infektion usw. Sie alle müssen Patientendokumentdateien analysieren und Daten in die Datenbank hochladen. Natürlich ist die Art der Daten für jede Abteilung leicht unterschiedlich. Wenn ich Paket-by-Funktion verwendet wird, hätte ich

com.company.neurology 
     Neurology.java 
     NeurologyDocument.java 
     NeurologyDAO.java 

com.company.infection 
     Infection.java 
     InfectionDocument.java 
     InfectionDAO.java 

usw. Das Problem ist, dass ich eine abstrakte Klasse brauchen, dass die Dokumentenklassen zum Beispiel verlängern müssen

AbstractDocument.java 
public class AbstractDocument 
{ 
     public void validateDocument(){...} 
     public void readDocumentHeader(){...} 
     public void readDocumentFooter(){...} 
     ... 
} 

Einige Datenzugriffsdateien, z.

DBConnection.java 
    public class DBConnection 
    { 
     public void makeConnectionToDB() {... } 
     public void createCache() {... } 
     public void closeConnectionToDB() {... } 
    } 

einige Fehlerklassen

ParseError.java, PatientNotFoundException etc. 

Wenn Pakete nach Merkmal sind, wo gehen diese gemeinsamen Klassen/Schnittstellen?

Answer 1

Ich würde empfehlen, die Dinge einfach zu halten. Vorausgesetzt, Sie werden nicht faul darüber, setzen Sie sie in com.company ist eine vernünftige Lösung.

Der Vorbehalt hier ist, dass dies die Disziplin erfordert, diese in separate Pakete zu verschieben, wenn Sie Gruppen von organisatorischen Gemeinsamkeiten feststellen.

Im Fall von Ihrem Beispiel haben Sie bereits damit begonnen, diese Verbindungen herzustellen - Ihre Post selbst segmentiert ist, diese zusätzlichen Pakete vorschlagen:

com.company.dataaccess 
com.company.error 

AbstractDocument.java wahrscheinlich nicht, dass es eigenes Paket nicht verdient - noch . Wenn Sie am Ende mehr verwandte Schnittstellen/Klassen erstellen, verschieben Sie diese in ein geeignetes Paket, aber nehmen Sie sich keine Sorgen, indem Sie sich darum sorgen, bis es tatsächlich zu einem Problem wird.

Answer 2

Ich glaube nicht, in Ihrem Fall sollten Sie einige common Paket erstellen. Ich denke, mit den verwendeten Abstraktionen stimmt etwas nicht.

Sie müssen einen Weg finden, Klassen mit dem gleichen Zweck in ein Paket zu vereinigen und dieses Paket unter com.company.shared.<feature_name> zu platzieren.

In Ihrem Fall könnte es sein:

• com.company.shared.database
• com.company.shared.data_parsing

Es ist kein Problem für ein Paket nur enthalten eine oder zwei Klassen. Aber es sollte nur Klassen mit demselben Zweck vereinen und einen klar sprechenden Namen haben.

Vermeiden Sie solche Namen für beide Pakete und Klassen wie common. Ein Name sollte für sich selbst sprechen.