# Zwei Fragen zum Design



## PHB (17. Mai 2018)

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 (17. Mai 2018)

Moin,


PHB hat gesagt.:


> 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 (17. Mai 2018)

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 (17. Mai 2018)

> 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 (17. Mai 2018)

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 (17. Mai 2018)

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 (17. Mai 2018)

PHB hat gesagt.:


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





PHB hat gesagt.:


> 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?




PHB hat gesagt.:


> 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 (17. Mai 2018)

mrBrown hat gesagt.:


> 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.



mrBrown hat gesagt.:


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


In meiner Welt schon 



mrBrown hat gesagt.:


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


Ja, das stimmt


----------



## mrBrown (17. Mai 2018)

PHB hat gesagt.:


> 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.




PHB hat gesagt.:


> In meiner Welt schon


Was ist denn für dich der Unterschied?


----------



## Thallius (17. Mai 2018)

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 (17. Mai 2018)

Thallius hat gesagt.:


> 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 (18. Mai 2018)

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 (18. Mai 2018)

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


----------



## PHB (18. Mai 2018)

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 (18. Mai 2018)

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 (18. Mai 2018)

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 (18. Mai 2018)

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?


----------

