Klassen verwalten, wie macht ihr das? Was ist sinnvoll?

**Tyrael Y.**

Hm...wie schon erwähnt benutze ich überhaupt keine Units mit reinen Funktionen mehr.

Der Vorteil von Klassen-Methoden ist, dass du die Funktionen in solchen Klassen sehr gut Gruppieren kannst.

Ich finde einen Karteikasten mit sehr vielen Karteikarten viel schöner
als ein Rolle Papier aus einem Drucker, daß immer weiter beschrieben wird.

**stoxx**

Klassen = Komplexität verbergen. (Zitat nach Hagen, das war der beste Ratschlag meines Lebens

Wenn ich etwas programmiere und ich weiß, dass ich diese Aufgabenstellung noch einmal benötigen könnte, dann möchte ich diese das nächste mal mit 3 Zeilen Code erledigt haben (Programmieren nach dem Konzept der "Faulheit" ... und gar nicht mehr wissen, was intern geschickt.

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

**BAMatze**

Zitat von stoxx:

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Ja sowas möchte ich mir ja auch jetzt langsam mal anlegen. Finde die Möglichkeit etwas in Klassen zu packen, um dann bestimmte Vorgänge intern regeln zu können sehr schön. Für mich stehen da aber wie man merkt noch einige Fragen offen, die dann bei der Umsetzung eines Programms wichtig sind. Möchte ja nicht heute eine schöne und umfangreiche Arbeit machen, um später festzustellen, Mensch schön dass ich das alles fertig gemacht hab, aber verwenden kann ich es nicht, weil irgendein Fehler im vorherigen Denken anlag(z.B. ich leg jetzt nur Units an und nachher kann ich sie nicht in eine Komponente einbinden).

MfG Bamatze

**Namenloser**

Zitat von stoxx:

Klassen = Komplexität verbergen. (Zitat nach Hagen, das war der beste Ratschlag meines Lebens

Wenn ich etwas programmiere und ich weiß, dass ich diese Aufgabenstellung noch einmal benötigen könnte, dann möchte ich diese das nächste mal mit 3 Zeilen Code erledigt haben (Programmieren nach dem Konzept der "Faulheit" ... und gar nicht mehr wissen, was intern geschickt.

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Da gebe ich dir recht (ich programmiere selbst sehr objektorientiert), aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit ist, oder intuitiver oder praktischer zu benutzen, weil verschachtelbar oder oder oder...

Ich persönlich binde eigene "Bibliotheken" eigentlich genau so ein, wie fremde. Ich kopiere sie aus dem Entwicklungsverzeichnis in mein Lib-Verzeichnis (ein eigenes, nicht das von Delphi, weil mir das sonst zu unübersichtlich wäre) und binde dann die Unit ein. Dieses Verzeichnis ist teilweise wieder in Unterverzeichnisse gegliedert, um die Übersicht zu behalten. Das hat leider den Nachteil, dass ich z.B. bei einer Neuinstallation mordmäßig viel zeug in die Bibliothekspfade eintragen muss. Das mit den Packages finde ich sehr clever, bin bisher nie darauf gekommen, die so zu nutzen, werde das aber glaube ich in Zukunft auch so machen.

**stoxx**

Zitat:

Da gebe ich dir recht (ich programmiere selbst sehr objektorientiert), aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit ist, oder intuitiver oder praktischer zu benutzen, weil verschachtelbar oder oder oder...

nur bedingt .. zu jeder function gehören auch Daten. Wenn es nicht gerade die Funktion "now" ist, die nur die aktuelle Uhrzeit zurückgibt.
Und wenn jemand der eigenen persönlichen Einbildung unterliegt, ein Funktionsaufruf in einer Klasse wäre soviel langsamer als ein direkter Funktionsaufruf, dem seien die neuen Records ans Herz gelegt.

ob man nun Data.calc, oder function Calc(const aData: TMyData); aufruft ..
ist letztendlich gleich und wird vom Compiler in gleicher Weise umgesetzt ...

Zitat:

aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit

als 10 Finger-tipper stören immer die vielen Klammern ... so ein Punkt bei data.calc ist viel schneller aufgerufen

**Hansa**

Zitat von stoxx:

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Das gilt aber auch für Forms oder Projekte. Hier fangen vermutlich 95 % mit einem neuen leeren Formular an. Dann wird angepasst. Die Schriften/Größen, die Farben, Captions usw. Im Prinzip wird immer wieder ein und dassselbe neu gemacht. Für jemand, der nur ein Formular in einem einzigen Projekt hat, der kann das auch so machen. Alle anderen sind durch diese Vorgehensweise aber schlecht beraten. Bei mir ist es z.B. immer so, dass eine Form mit esc geschlossen werden kann, oder es mit Enter in einem Grid weiter geht. Das ist den ISO-Normen geschuldet. Weder Alt-F4 noch Tab nach Win-"Standard" sind ISO-konform. Statt nun tatsächlich mit neuem leeren Formular anzufangen nehme mich mir zumindest eines aus der Objektablage, was dieses Minimum schon kann. Im Laufe der Zeit hat sich so schon eine beachtliche Anzahl immer ausgefeilterer Formulare angesammelt. Ich brauche mir für einen gewissen Zweck nur das richtige auszusuchen und 80 % der Arbeit ist bereits erledigt ! Im Endeffekt kommt dann dabei heraus, dass äußerst komplexe Formulare tatsächlich nur 100 Zeilen haben.