Welchen Vorteil hat es, Programmablauflogik und Daten zu trennen? Bisher kenne ich es so, dass bei prozedural IN EINER KLASSE Daten und Operationen darauf definiert sind. Wieso sollte man es nicht so machen? Und warum muss man dann allen Methoden Referenz(en) auf das Daten-Objekt geben?
Klassen sollen genau einen Zweck haben. Wenn du eine Klasse “Person” hast, soll sie eine Person repräsentieren. Sie soll **nicht **gleichzeichtig wissen, wie sie sich in der Datenbank zu speichern hat, woher die Referenzen auf die Lohnbuchhaltung und den Eventbus kommen, wie sie als JSON representiert werden kann, oder ob sie single- oder multithreaded verwendet wird. Jede Abhängigkeit, die eine Klasse **nicht **hat, und jeder Annahme über ihre Verwendung, die eine Klasse **nicht **trifft, macht sie flexibler, robuster und leichter zu testen.
Nehmen wir als Beispiel einmal Comparable vs Comparator. Für Klassen, die eine natürliche Ordnung haben und Sortierbarkeit sozusagen Teil ihres “Aufgabengebiets” ist (etwa Zahlen), ist es eine gute und bequeme Wahl, Comparable zu implementieren. Für eine Klasse wie Person ist Sortierbarkeit dagegen keine “Kernkompetenz”, deshalb ist es sinnvoll, diese Funktionalität in einen oder mehrere Comparatoren auszulagern. Diese müssen die Personen natürlich übergeben bekommen, das Handling ist etwas umständlicher u.s.w., aber die dadurch gewonnene Flexibilität wiegt das normalerweise locker auf.
Das meinte ich auch nicht. Nehmen wir an, eine Klasse PERSON. Wieso dann eine Klasse mit einer Liste von Personen und wieso eine Klasse mit einer Klasse/Variablen von einer Klasse mit einer Liste von Personen? Das ist für mich Nonsens.
Je tiefer in der Hierarchie die Klasse PERSON steht, desto schwieriger wird es, mit PERSON/Personen “umzugehen”. Das meinte ich damit.
Ich verstehe ehrlich nicht ganz, was du meinst - und das jetzt klingt auch ganz anders als der Eingangspost.
Wo hast du diese Weisheiten her? Wenn ich eine Liste von Personen haben will, nehme ich auch eine Liste. Wenn ich eine andere, spezielle Gruppierung von Personen benötige, schreibe ich meine eigene Klasse (die eventuell intern eine Liste von Personen hält).
Die Frage ist, ob die “Gruppe von Personen” eigenständig ist, z.B. zusätzliche Informationen beinhaltet oder besondere Regeln für den Umgang mit Personen erfordert. Ist das der Fall, rechtfertigt das eine eigene Klasse, ansonsten tut es auch eine der Collection-Klassen. Ich weiß, dass früher(?) hin und wieder propagiert wurde, **immer **eine Wrapper-Klasse für Listen von anderen Klassen u.s.w. zu verwenden, aber das ist Blödsinn, solange diese keinen eigenständigen Character hat.
[quote=CyborgBeta]Bisher kenne ich es so, dass bei prozedural IN EINER KLASSE Daten und Operationen darauf definiert sind.[/quote]Ich dagegen wusste gar nicht, dass man in einer prozeduralen Spache Klassen hat…
bye
TT
Das meinte ich. Ich habe eine Datenklasse, in einer anderen Klasse haben ich eine Liste von Datenklassen und wieder in einer anderen Klasse habe ich eine Variable auf die Klasse mit einer einer Liste von Datenklassen.
Siehe hier:
Präsentationsschicht
Steuerungsschicht
Geschäftslogikschicht
Datenzugriffsschicht
Komponente 2 bis Komponente n könnte in Komponente 1 zusammengefasst werden. Komponente 1 ist dann lediglich etwas länger.
Konkret schreibe ich einen Bot für ein Browserspiel, das schnell und robust sein soll. Alle Variablen in Data könnten auch in der Logik stehen, denn alle Daten sind nur während das Programm läuft vorhanden, ohne Persistierung.
Wenn gewünscht, kann ich die Klasse Data mal posten, um das alles zu verdeutlichen.
** EDIT **
[QUOTE=Timothy_Truckle;136128]Ich dagegen wusste gar nicht, dass man in einer prozeduralen Spache Klassen hat…
:D[/QUOTE]
Java ist für mich prozedural und gleichzeitig OO. 
** EDIT **
Die Klasse Data sieht so:
[SPOILER]```class Data {
float geld;
float promille;
boolean skills;
boolean fight;
int wechselkurs;
boolean activities;
int id;
int lebenspunkte;
boolean warteschlange;
int flaschen;
int prozent;
int kurs;
ArrayList<Object[]> weiterbilden = null;
Data() {
}
@Override
public String toString() {
return "Data{" + "geld=" + geld + ", promille=" + promille + ", skills=" + skills + ", fight=" + fight + ", wechselkurs=" + wechselkurs + ", activities=" + activities + ", id=" + id + ", lebenspunkte=" + lebenspunkte + ", warteschlange=" + warteschlange + ", flaschen=" + flaschen + ", prozent=" + prozent + ", kurs=" + kurs + ", weiterbilden=" + weiterbilden + '}';
}```[/SPOILER]
Teile der Logik stehen aber in den Settern von Data. Somit wäre es für mich sinnvoller, alle Variablen aus Data in die Logik zu übernehmen…
[quote=Landei]Ich weiß, dass früher(?) hin und wieder propagiert wurde, immer eine Wrapper-Klasse für Listen von anderen Klassen u.s.w. zu verwenden, aber das ist Blödsinn, solange diese keinen eigenständigen Character hat.[/quote]Das war, bevor es Generics gab.
Das war die Einzige Möglichkeit, eine typesafe Collection zu bekommen. Das als “Blödsinn” abzustempeln halte ich für ein wenig überheblich.
bye
TT
[OT]Wrapper-Klasse für Listen von anderen Klassen können in Einzelfällen auch immer noch Sinn machen.
Ich habe sowas in einem Projekt verwendet, wo die “andre” Klasse ein schlichter String war, und das aus mehreren Gründen:
[ol]
[li]List<String> ist wenig aussagekräftig.[/li][li]Ein List<String>-Objekt kann einen Haufen von Dingen, die in dem Zusammenhang unwichtig waren[/li][/ol]
[/OT]
[QUOTE=Timothy_Truckle;136131]Das war, bevor es Generics gab.
Das war die Einzige Möglichkeit, eine typesafe Collection zu bekommen. Das als “Blödsinn” abzustempeln halte ich für ein wenig überheblich.
bye
TT[/QUOTE]
Für die Typsicherheit ist es ja noch einzusehen, aber heutzutage ist es eben Blödsinn.
[OT]Es finden sich ja immer wieder “Best Practices”, die einmal durchaus sinnvoll waren, aber von Leuten, die ihren Sinn nicht richtig verstanden haben, dann sinnlos und dogmatisch weiter eingesetzt wurden, obwohl sie (die Best Practises, nicht die Leute) schon längst überflüssig geworden waren. Bestes Beispiel ist wohl die Ungarische Notation für Variablen.[/OT]
[OT][quote=Landei]aber heutzutage ist es eben Blödsinn.[/quote]heut zu tage ja, aber Du schrubst:
bye
TT
[QUOTE=Crian][OT]Wrapper-Klasse für Listen von anderen Klassen können in Einzelfällen auch immer noch Sinn machen.
Ich habe sowas in einem Projekt verwendet, wo die “andre” Klasse ein schlichter String war, und das aus mehreren Gründen:
[ol]
[li]List<String> ist wenig aussagekräftig.[/li][li]Ein List<String>-Objekt kann einen Haufen von Dingen, die in dem Zusammenhang unwichtig waren[/li][/ol]
[/OT][/QUOTE]
Dann wäre es aber normalerweise sinnvoller, den “schlichten String” zu einer Klasse zu “befördern”, statt die Liste zu einem Wrapper-Typ (wobei natürlich immer Performance oder Speicherplatz dagegen sprechen können)