Wo gehören die Variablen hin?

[Bjoerk]

Zitat von Furtbichler:

Die Frage ist doch nicht die, wo die Variablen hingehören, sondern eher die, wo die Funktionalität hingehört. Dann ergibt sich der Rest von ganz alleine.

Das ist mal Antwort, mit der ich was anfangen kann. Danke dafür.

Was mir heute nach aber nochmal klar geworden ist, daß es bei mir weniger ein Frage von prozedural vs. OO ist, sondern die ganzen Kopplungen. Aus einer procedure eine Methode zu machen ist m.E. noch lange nicht objektorientiert. Meine ganzen globalen Variablen waren ja auch prozedural schon schlechter Programmierstil. Ich hab jetzt eine eigene Datenklasse, die jede Klasse unter private dazu komponiert bekommt.

Und, wenn ich manchmal bei prozedural bleibe, bei machen Projekten spricht einiges dafür, könnte das sogar ein Record mit einer LoadFromDatenBasis sein, gab‘s früher leider noch nicht, der Code ist teilweise noch mit Delphi 1 bzw. unter DOS Turbopascal 7 geschrieben, doch auch damals war beispielsweise ein Gauss Algorithmus schon dasselbe wie heute.

Gruß und schönen Sonntag
Thomas

[Furtbichler]

Zitat von Bjoerk:

Ich hab jetzt eine eigene Datenklasse, die jede Klasse unter private dazu komponiert bekommt.

Nee. Das verstößt gegen diverse Regeln. So ist diese Datenklasse für alle anderen Klassen zuständig und muss auch von ihnen wissen. Wozu? Kommt eine Klasse dazu, muss die Datenklasse mit geändert werden. Warum?

Eine Klasse ist ein Container für eine Funktionalität. "Daten vorhalten" ist keine Funktionalität, sondern eine Ausrede .

Wenn Du es richtig richtig machen willst, skizziere die Funktion(alität)en, Interaktionen und Abhängigkeiten in dem Programm. Dann hast Du eigenntlich schon eine grobe Klassenstruktur. In jeder Klasse, die immer noch ziemlich viel Codebeinhaltet, machst Du das Gleiche. Du kommst zu Klassen, deren Sinn Du in 1-2 Sätzen erklären kannst. Die Methoden werden dann so lange verfeinert (=refaktorisiert), bis jede Methode ohne das Wort "und" beschrieben werden kann, d.h. sie macht dann genau eine Sache.

Klassen mit ähnlicher Funktionalität (Laden und speichern z.B.) lassen sich zu Klassenfamilien zusammenfassen. Die Gemeinsamkeiten kommen in eine Basisklasse, die Besonderheiten in die einzelnen Ableitungen. Doch Vorsicht: Auch hier gilt: Nicht alles, was so komponiert wird, ist gutes OOP.

Gutes OOP ist wie gutes Essen. Es schmeckt, aber wie man es hinbekommt, ist eine Kunst. Und Kunst fällt nicht vom Himmel (außer vielleicht bei Beuys, der eine Badewanne unter einen vom Himmel fallenden Butterklumpen stellt) sondern muss gelernt werden.

Fang einfach an und lies Bücher darüber.

[Bjoerk]

Mir schwant, mein Softwareprodukt ist mir über den Kopf gewachsen.

Die Struktur der einzelnen Programme ist so. Jetzt wollte ich aus A bis G Datenklassen machen (siehe unten).

Delphi-Quellcode:

Lies die Daten die der Benutzer eingegeben hat (Output = A)

Ergänze die Daten durch weitere umfangreiche Daten (Input A, Output B)

Mach daraus ein Statisches System (Input A+B, Output C)

Berechne N mal das System (Input A+B+C, Output D)

Ermittele aus den N Berechnungen maßgebende Bemessungskombinationen K (Input A+B+C+D, sehr umfangreicher Output E)

Bemesse das System für diese Kombinationen (Input A+B+C+D+E, Output F)

Zeige in Tabellenform alle Daten und Ergebnisse und stelle diese grafisch dar (Input A+B+C+D+E+F, Output G = Result)