Wo gehören die Variablen hin?

[Bjoerk]

Crosspost Delpi-Treff

Ich stelle zurzeit meine Software von prozedural nach OO um. Dabei habe ich oft folgende Situation, mit der ich nicht weiß, wie ich sie handhaben soll.

Wäre dankbar für eine Idee, mir fällt nix Gescheites ein..

Situation: Die Units werden bisher mit globalen Variablen über die uses Klausel versorgt.

Delphi-Quellcode:

unit unit1;

uses
  unitA, unitB, unitC;

var
  O: TKlasse;
  u, v, w: ...

procedure TForm1.Machwas;
begin
  // Globale Variable x aus unitA;
  // Globale Variable y aus unitB;
  // Globale Variable z aus unitC;
  Setzt u, v
  Führt O.Machwas aus
  Benötigt die von O.Machwas veränderten Werte x, y, z, u, v zur weiteren Berechnung
end;


unit TKlasseUnit;

uses
  unit1, unitA, unitB, unitC;

  // Globale Variable x aus unitA;
  // Globale Variable y aus unitB;
  // Globale Variable z aus unitC;
  // Globale Variablen u, v aus unit1;

procedure TKlasse.Machwas;
begin
  // benötigt und verändert x, y, z, u, v
end;

[bernhard_LA]

schon mal unter Delphi class , private, public geggogelt ?

zB.

http://de.wikibooks.org/wiki/Program...ascal:_Klassen

[himitsu]

Variablen gehören da hin, wo sie verwendet werden.

Wird sie lokal nur in einer Funktion/Prozedur/Methode verwendet, dann gehört sie in diese Funktion rein.

Wird sie innerhalb einer Klasse verwendet, dann gehört sie dort hin, also in die Klassendeklaration. (wie Bernd erwähnt hat, z.B. in private oder protected)

Wird sie global benötigt, würde man sie global deklarieren, aber Global ist nicht global.
Wird sie in einer Klasse erstell/freigegeben, denn gehört sie in die entsprechende Klasse (private/protected) und man veröffentlicht sie z.B. über ein public-Property.
Notfalls gibt es noch Class-Var und Class-Property, wenn diese Variable zwar an eine Klasse, aber nicht an eine bestimmte Objekt-Instanz gebunden ist.

[Bjoerk]

class var ? Seit wann gibt's die denn?

Himitsu, wenn ich zwei Klassen habe, die Daten austauschen, wo machst du die Variablen dann hin? Egal ??? Da muß es doch Prinzipien geben ?

Bernard, ich hab schon einige Klassen geschrieben und ich weiß auch was eine property ist, das ist hier nicht das Problem.

[vagtler]

Zitat:

Zitat von Bjoerk (Beitrag 1155872)

class var ? Seit wann gibt's die denn? [...]

Seit Delphi 7.

[Lemmy]

Zitat:

Zitat von Bjoerk (Beitrag 1155872)

Himitsu, wenn ich zwei Klassen habe, die Daten austauschen, wo machst du die Variablen dann hin? Egal ??? Da muß es doch Prinzipien geben ?

Klar gibts dafür Prinzipien - aber dazu müsste man wissen was denn die Klassen machen und was die Daten für eine Bedeutung haben. Ggf. kann es auch sein, dass die Daten in eine dritte Klasse gehören - pauschal lässt sich das aber nicht sagen.

[Bjoerk]

:oops: Peinlich, wußte ich nicht. Hab nur gelegentlich mal class procedures und class functions benutzt: Thanx!

[Bjoerk]

Lemmy, das Ding ist aus den Neunzigern. Ursprünglich war alles prozedural. Dann sind mit der Zeit einige nicht visuelle Komponenten hinzugekommen, die alle die gleichen Daten brauchen.

[Bjoerk]

Bernhard, dein Link konnte mir jetzt doch weiterhelfen. Bin beim Stöbern auf das gestoßen. Das passt.

Gruß
Thomas

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

Die hier gegebenen Antworten "dort, wo sie gebraucht werden"

In deinem Beispiel fragt man sich, was die TKlasse mit den Werten x,y,z,u,v denn 'macht'. Und weshalb die in anderen Units deklariert sind bzw. wurden.

Ach, so -wuppdiwupp- vom prozeduralen auf den objektorientierten Ansatz umzuschwenken, ist dann doch nicht ganz so einfach, vor allen Dingen dann, wenn man solche Fragen stellt. Da scheint dann das Grundverständnis zu fehlen. Macht aber nichts, das ging uns allen so.

Also: Basiswissen aneignen, Bücher schmöckern, die Prinzipienm Stärken und Schwächen von OOP verstehen.

[Bjoerk]

Zitat:

Zitat von Furtbichler (Beitrag 1155916)

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:

Zitat von Bjoerk (Beitrag 1155940)

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

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. :oops: :shock:

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)