Zwei Fragen zum Design

[PHB]

Hallo zusammen,

wenn ihr mehrere Konten verwalten müsstet, würdet ihr dann eine Konto-Klasse und eine Konten-Klasse erstellen, die eine Liste/Array/Collection plus ein paar Methoden anbietet?

Würdet ihr das dann auch für Gruppe/Gruppen, Auto/Autos .... etc. tun?

Ich frage deshalb, da ich mich gerade mit dem Thema Entwurfsmuster zu beschäftigen versuche. Nach dem DRY-Prinzip (Dont Repeat Yourself) wäre ja eine Menge Code in den Plural-Klassen redundant.

Wäre es nicht sinnvoller mit den Singular-Klassen zu arbeiten, die dann so eine Art Adapter-Klasse aufrufen sowie die Objekt-Erstellung und -Verwaltung (für alle Objekte) dort gebündelt dem Adapter überlassen. Gibt es dafür vielleicht sogar ein passendes Entwurfsmuster?

 

[VfL_Freak]

Moin,

würdet ihr dann eine Konto-Klasse und eine Konten-Klasse erstellen
...
Würdet ihr das dann auch für Gruppe/Gruppen, Auto/Autos .... etc. tun?

ääh ... nein ... ?!?
Es sei denn, Du erklärst mal, worin für Dich der Unterschied bestehen soll?

Wenn ich mehrere Instanzen vom Typ 'Konto' habe, brauche doch eigentlich zu deren Verwaltung keine eigene weitere Klasse!
Oder verstehe ich hier etwas völlig falsch ??

VG Klaus

 

[PHB]

Das ist eben die Frage, ob es guter Stil wäre, in einer Klasse "Person" über ein Array auch gleich alle Personen zu verwalten oder ob man das nicht lieber in eine Klasse "Personen" implementieren würde?

Es gib ja beispielsweise auch org.w3c.dom.Node und org.w3c.dom.NodeList

 

[Elenteria]

würdet ihr dann eine Konto-Klasse und eine Konten-Klasse erstellen

nein würde nicht mit ziemlicher Sicherheit nicht so machen. Bei mir hätten alle Klassen die mit mehreren Konten arbeiten (z.b. Bank, Kunde, etc) eine Liste/Map/Set/Whatever von Konten.

 

[PHB]

Ich bin gerade etwas unsicher
Im Dotnet ist oft so etwas vertreten: XmlAttributeCollection und XmlAttribute

Wenn man alles in eine Klasse steckt, verletzt es meiner Meinung nach das SOLID-Prinzip, da der Klasse nicht mehr nur eine Aufgabe zugeteilt wird.

 

[stg]

Ich kenne die dotnet-Dinger nicht, aber allein dem Namen nach vermute ich dahinter fachlich getrieben ein Kompositum-Pattern, damit du XML-Attribute gruppiert genauso behandeln kannst, wie ein einzelnes XML-Attribut.

 

[mrBrown]

Nach dem DRY-Prinzip (Dont Repeat Yourself) wäre ja eine Menge Code in den Plural-Klassen redundant.

Wenn man alles in eine Klasse steckt, verletzt es meiner Meinung nach das SOLID-Prinzip, da der Klasse nicht mehr nur eine Aufgabe zugeteilt wird.

Wo wäre da Code redundant und welche verschiedenen (fachlichen) Aufgaben würden der Klasse denn zugeteilt werden?

Wäre es nicht sinnvoller mit den Singular-Klassen zu arbeiten, die dann so eine Art Adapter-Klasse aufrufen sowie die Objekt-Erstellung und -Verwaltung (für alle Objekte) dort gebündelt dem Adapter überlassen. Gibt es dafür vielleicht sogar ein passendes Entwurfsmuster?

Wäre nicht eine "Konten"-Klasse das, was du damit grad beschreibst (wenn wir sie einfach mal "KontoAdapter" nennen)?



Aber für das was du beschreibst, gibt es gefühlt 42 Lösungswege.
Je nach Domäne kann's verschiedene Lösungen gebe, u.U. passt das Repository-Pattern, vielleicht auch was völlig anderes...

 

[PHB]

Wo wäre da Code redundant und welche verschiedenen (fachlichen) Aufgaben würden der Klasse denn zugeteilt werden?

Na ja, zum Beispiel wenn man zig Collection-Funktionalitäten in die verschiedenen Klassen steckt, wo sich innerhalb der Ausprogrammierung nur marginal Unterschiede ergeben.

Wäre nicht eine "Konten"-Klasse das, was du damit grad beschreibst (wenn wir sie einfach mal "KontoAdapter" nennen)?

In meiner Welt schon

Aber für das was du beschreibst, gibt es gefühlt 42 Lösungswege.

Ja, das stimmt

 

[mrBrown]

Na ja, zum Beispiel wenn man zig Collection-Funktionalitäten in die verschiedenen Klassen steckt, wo sich innerhalb der Ausprogrammierung nur marginal Unterschiede ergeben.

Die Collection-Funktionalität würde man z.B. an eine entsprechende Collection weiter delegieren.

In meiner Welt schon

Was ist denn für dich der Unterschied?

 

[Thallius]

Denk doch einfach mal in Objekten. Wenn du eine Liste von Konten brauchst, dann ist sie ja wahrscheinlich Bestandteil von irgend etwas. Also zum Beispiel alle Konten einer Bank. Damit würdest du also eine Klasse Bank brauchen die eine Liste mit Konten hat. Wenn du eine Liste mit Banken brauchst dann vielleicht DeutscheBanken und so weiter und so weiter. Irgendwann wirst du aber an einen Root Knoten kommen über den du eigentlich nicht mehr hinaus musst für eben deine Anwendung. Wenn du also nur die Konten von einer Bank brauchst, dann macht es keinen Sinn eine Klasse Bank zu erstellen. In dem Fall würde eine Liste mit Konten das Root Objekt deiner Applikation darstellen.

Gruß

Claus

 

[PHB]

Denk doch einfach mal in Objekten. Wenn du eine Liste von Konten brauchst, dann ist sie ja wahrscheinlich Bestandteil von irgend etwas. Also zum Beispiel alle Konten einer Bank. Damit würdest du also eine Klasse Bank brauchen die eine Liste mit Konten hat. Wenn du eine Liste mit Banken brauchst dann vielleicht DeutscheBanken und so weiter und so weiter. Irgendwann wirst du aber an einen Root Knoten kommen über den du eigentlich nicht mehr hinaus musst für eben deine Anwendung. Wenn du also nur die Konten von einer Bank brauchst, dann macht es keinen Sinn eine Klasse Bank zu erstellen. In dem Fall würde eine Liste mit Konten das Root Objekt deiner Applikation darstellen.

Gruß

Claus

Ja, kann man so tun. Dann wäre die Root-Klasse "Application". Diese würde dann Konten und Benutzer verwalten. Alle anderen Objekte würde dann im entsprechenden Konto-Objekt gehalten/verwaltet werden.

 

[PHB]

Ich lade mal meine aktuell Modelversion hoch.

Mir geht es um die Klassen: Benutzerkonten, Textbausteine, Konten, Zahlungsuebersichten, Finanzplansichten, Zahlungen und Gruppen.
Die werden im Grunde alles dasselbe tun. Deshalb habe ich überlegt, ob es sinnvoll wäre, die durch eine Klasse auszutauschen.

 

[mrBrown]

So wie sie da benutzt werden, sind sie wirklich überflüssig und können einfach durch eine passende Collection ersetzt werden

 

[PHB]

Wie genau meinst du das?

Eine Collection-Klasse für alle Model-Klassen (Konto, Benutzer, Textbaustein usw.)
oder
je eine Collection in jeder Model-Klasse?

Die zweite Variante ist ja genau das, was ich nicht möchte. In der Klasse Benutzerkonto gehört m.M.n. keine Collection hinein, die unendlich viele Benutzerkonten hält.

 

[mrBrown]

Da, wo jetzt zB "Konten" benutz wird, ersetzt du es durch "List<Konto>" (oder das entsprechend passende).
Im Model würde das bedeuten, einfach alle "Plural"-Klassen ersatzlos zu streichen: Benutzerkonto <>--*- Konto
anstatt Benutzerkonto <>--1- Konten <>--*- Konto

 

[httpdigest]

Ich glaube, er meint, die Klasse Benutzerkonten ist doch exakt und haargenau dasselbe wie eine List<Benutzerkonto>. Sie macht doch anscheinend absolut nichts anderes als die List/Collection Methoden zu reimplementieren und an die enthaltene `list` zu delegieren.
Das heißt: Lösche die Klasse "Benutzerkonten" und ändere den Typ in "App" von dem Feld benutzerkonten und aktiveBenutzer (soweit ich das aus dem Bild richtig lesen kann) von "Benutzerkonten" nach java.util.List<Benutzerkonto>. Fertig.
Dasselbe gilt übrigens für die Klassen "Konten", "Textbausteine", "Zahlungsuebersichten", "Finanzplansichten", "Zahlungen" und "Gruppen". Alle diese Klassen sind absolut überflüssig, da sie ja nur eine enthaltene Liste kapseln und durchdelegieren.

 

[PHB]

Ah, danke euch. Ihr meint es so, wie unten zu sehen, oder?
Gefällt mir, warum bin ich da nicht selbst drauf gekommen
Das ist eben der Unterschied von einem der als Anfänger (Junior) noch wenig Erfahrung hat zu einem Senior, der sich seit Jahren damit beschäftigt.
Ich hoffe, ich habe euch mit meiner Anfänger-Frage nicht allzu sehr gelangweilt?