Klassen Organisationsstruktur

[kaoZ]

Aloha, ich steh zzt. vor einer Organisatorischen Entscheidung, um Bezug auf die Struktur einer Kundenverwaltung.

Ich Rätsel seit Tagen wie ich das ganze durchstrukturiere.....

Mein Ansatz

Abstrakte Basisklasse

Client

Beinhaltet Attribute für Name, Adresse und Kundennummer
und stellt zudem realisierte Getter dafür zu Verfügung stellt.

-konkretisierte Subklasse

BusinessClient

-konkretisierte Subklasse

PrivateClient

Beide würden das

Interface Editable implementieren,

welches ich (unschlüssiger weise) entweder als Marker Interface nutzen würde, oder darüber

direkt die Methoden

edit();

save();

remove();

bereitstelle, welche dann von den Unterklassen realisiert werden müssten.
( Was würde mehr Sinn machen ?)

Zudem spiele ich mit dem Gedanken , die Objekt Erstellung über eine ClientFactory zu regeln.

Wie würdet ihr die Sache angehen ? für Vorschläge bin ich jederzeit dankbar

 

[ry_void]

Das ist nicht ganz leicht zu beantworten: Einerseits, ja. Wenn es genau das macht was du willst ist es richtig. Andererseits habe ich mir angewöhnt für Objekte wie "Client" oder "Kunde" eine Controller Klasse anzulegen die sich um solche CRUDMethoden kümmert.

Es gibt auch eine Unmenge an Patterns die solche Sachen auflösen sollen.

Ansehenswert ist vielleicht auch noch das hier.

 

[KSG9|sebastian]

Was sollen denn die Methoden edit/save/remove tun?

Wie unterscheiden sich Private/BusinessClient?
Was würde die ClientFactory tun? Etwa

class ClientFactory {
  private static final ClientFactory instance = new ClientFactory();

  public static ClientFactory getFactory(){
     return instance;
  }

  public PrivateClient createPrivateClient(){
    return new PrivateClient();
  }

}

Sowas etwa? Falls ja vergiss es, werf's weg. Das sind 10 Zeilen nutzloser Code der keinerlei Mehrwert bietet!

 

[kaoZ]

Naja , also ich nutze keine Datenbank, das mal vorab, die Software soll nur auf einem Rechner laufen und meinem alten Herren die Arbeit erleichtern und da lohnt sich der ganze Aufwand nicht , mir geht es nur darum es so übersichtlich wie möglich zu gestalten, die Kundendaten werden in zuvor im Setup erstellten Ordnern einfach in Textdateien geschrieben. (unserialisiert).

die Kunden unterscheiden sich in Anschrift, ( geschäftlich ) Kundennummer, und Speicherort, deswegen auch die getrennte Realisierung in den jeweiligen klassen,

[EDIT]
Anhand der Unterscheidung ob Privat oder Geschäftlich können später bestimmte Konditionen Festgelegt werden usw....
[/EDIT]

die Factory wollte ich nutzen das wenn ein neues Kundenobjekt erzeugt wird dies gekapselt in einer eigenen Klasse , eben der Factory über statische Methoden geschiet

public class ClientFactory{


public static Client createClient(String name, Address address, boolean isBusiness){

 if(isBusiness){
    return new BusinessClient(name, address, new ClientNumber(name, true)); 
 }
 else{
    return new PrivateClient(name, address, new ClientNumber(name, false));
 }

}
}

Der Aufruf soll einfach über

ClientFactory.createClient(String name, Address address, boolean isBusiness);

//bzw.

ClientFactory.createClient("Max Mustermann", new Address(...), true);

erfolgen.


Ich wollte halt lediglich zur Kapselung die Objekterzeugung auslagern.

 

[KSG9|sebastian]

Wenn sich der Unterschied über einen boolean-Parameter repräsentieren lässt macht es imho keinen Sinn dafür Vererbung zu nutzen - da kannst du genauso ein Attribut in der Person hinterlegen.

Was kapselst du denn mit der Factory? Man kapselt ja nicht um der Kapselung Willen.

An der Stelle Factories/Singletons und Zeug einzuziehen ist imho einfach nur sinnloses Over-Engineering. Einen Mehrwert hast du davon nicht.

 

[kaoZ]

Wenn sich der Unterschied über einen boolean-Parameter repräsentieren lässt macht es imho keinen Sinn dafür Vererbung zu nutzen

Allerdings wäre ein Geschäftskunde ebend z.B

"Autohaus XYZ"

welches wiederrum ggf. einen Ansprechpartner hat

ein Privatkunde hingegen

"Peter Müller"

deshalb ja die Unterscheidung zwischen Geschäft und Privatkunde, demnach dachte ich das die Ableitung einer Abstrakten Klasse Kunde und die Konkretisierung in Subklassen durchaus sinn machen würde , zu dem Thema mit der Over Engineering , ok zugegeben unbedingt notwendig ist es nicht aber ich fand es irgendwie eine saubere Lösung, wenn vielleicht auch ein klein wenig Overkill

 

[KSG9|sebastian]

Wenn sich die beiden Kunden weiter unterscheiden ist Vererbung schon richtig.

 

[kaoZ]

zu

edit();

save();

remove();

des Interface Editable

edit();

ermöglicht die Bearbeitung von Kundendaten

save();

ermöglicht das Spezifische speichern der Erstellten Kunden über eine Utility Klasse (welche unter anderem, ein Editable entgegennehmen kann)

remove();

ermöglicht es Kunden ( also Textdateien ) die Daten enthalten aus dem speziellen Verzeichniss zu entfernen.

 

[KSG9|sebastian]

Willst du das ganze an Domain-Driven-Design angelehnt bauen? Sonst würde ich dazu tendieren das speichern/änder/löschen außerhalb der Domänenobjekte zu machen.

 

[kaoZ]

Ich denke ich werde die Schreib/Lesezugriffe über eine Separate Utility Klasse regeln,
das Editable Interface werde ich als lediglich marker verwenden und den Methoden der Utility Klasse demnach die Möglichkeit bieten ein Editable entgegenzunehmen.


so in der Art:

Spoiler: FileHandler.java

public class FileHandler(){

 private File file;

public FileHandler(String filePath){
 this.file = new File(filePath);
}

public boolean save(Editable item){
  ...
}

public Object load(){
  ...
}

public void getPath(){
  ...
}
}

höchstwahrscheinlich schreibe ich die Daten dann auch direkt als Objekt (Serialisiert) in die einzelnen Dateien, das macht das einlesen denke ich wesentlich bequemer

[EDIT]
So kann ich mir dann auch die

edit()

Methode sparen und es über

save()

+

load()

realisieren, ist ja prinzipiell nichts anderes
[/EDIT]