Objekterzeugungen mit zur Laufzeit variierenden Attributen

[dvdlly]

Hallo,
Ich möchte eine Desktop Chat App schreiben und habe mir gedacht ich bastle ein Request Objekt dafür. Bisher sieht das so aus:

public class Request {

    private enum Type {START_CHAT, SEND_MSG, ADD_USER};
    private String message;
    private String sender;
    private String receiver;
    public String getMessage() {
        return message;
    }

    public String getSender() {
        return sender;
    }

    public String getReceiver() {
        return receiver;
    }
}

Nun gibt es folgendes Problem: Je nachdem, was für einen Enum Wert das Request Objekt hat, muss es die Felder message, firstname,lastname, sender, receiver haben oder eben nicht. Wie würdet ihr das am geschicktesten lösen? Ich habe entweder an eine Vererbungshierarchie gedacht, wobei mir das umständlich vorkommt, oder an ein "drübergelegtes" Interface, allerdings kann man das Objekt dann nicht mehr per ObjectInputStream verschicken oder?

 

[kneitzel]

Je nachdem, was für einen Enum Wert das Request Objekt hat, muss es die Felder message, firstname,lastname, sender, receiver haben oder eben nicht. Wie würdet ihr das am geschicktesten lösen?

Das deutet für mich darauf hin, dass es nicht einfach ein Enum sondern eine Klassenhirarchie sein sollte.
Dann hast Du die entsprechenden Klassen, die alle von Request erben. Ein Request hat nur, was alle Request gemein haben (also von mir aus das Feld sender) und die abgeleiteten Klassen haben dann das, was sie brauchen.

Das wäre so ein erster Ansatz. Man könnte aber auch eine generische Klasse überlegen, die dann nur die Daten hat, die alle haben (Also on mir aus ein Feld, das einen Enum nimmt und den Sender) und die optionalen Dinge sind dann alle in einer Map gespeichert.

Wenn man mehr wüsste vom geplanten Design, dann ist da ggf. auch noch deutlich mehr denkbar ...

 

[dvdlly]

Ich habe mir bisher nur gedacht, dass ich eine MVC Architektur benutzen möchte, Request Objekte werden auf der Client Seite vom Controller erzeugt und dann an einen Server verschickt bzw von dem Server zurück an den Controller. Musst du noch etwas wissen?

 

[dvdlly]

Man könnte es auch mit einer Factory auf der Client Seite lösen oder?

 

[Mart]

was eine Idee wäre ist es ein Objekt zu haben das einen Namen hat und ein Json Objekt und je nach namen wird es vom CLient bzw server interpretiert zb
mit dem Namen = "put"
interpretiert dein Server es danach..das würde deiner Enum entsprechen

 

[kneitzel]

Ob da später eine Factory Sinn macht oder nicht, ist erst einmal egal. Du musst ja erst einmal wissen, was Du herstellen willst.

Wichtiger ist dabei erst einmal, ob da noch irgendwelche Verhalten rein kommen oder nicht. Wenn es nur rein um Daten geht, die übertragen werden sollen, dann spielt da eine größere Aufsplittung in Klassen keine Rolle. Das könnte dann zur Not eine einfache Map sein oder so.

Verhalten könnte z.B. sein, dass bei der Registrierung eines Users auch eine Validierung stattfinden soll. Das könnte dann in der Klasse mit drin sein. Dann kann ein Client aber auch der Server prüfen, ob die Daten valide sind - und du hast den Code nur ein einziges Mal.

JSON ist für mich etwas, das ich bei einer Seralisierung nutze. Also um Daten von a nach b zu senden (Also z.B. in einem Webrequest). Aber ich würde vermeiden, da unnötig mit rumzuhantieren. Das ist in der Regel einfach zu komplex. Ein sauberes, objektorientiertes Model sollte in der Regel deutlich lesbareren Code erzeugen.

 

[dvdlly]

Danke, deine Idee bezüglich User Validierung finde ich gut

 

[dvdlly]

Ah wobei so wie meine Datenbank beschaffen ist wird immer eine sql exception geworfen, falls es einen user nicht gibt oder dergleichen