Guter Programmierstil

[ozz]

Hallo zusammen,
ich habe eine eher konzeptionelle Frage.

Angenommen ich habe eine Applikation, die eine Liste von Strings an eine Klasse übergeben soll. Wie wäre da die beste Herangehensweise.

Variante 1:
Ich kann in der Klasse eine function definieren, die Listen entgegennehmen kann.

Delphi-Quellcode:

function MYCLASS.Add(URL:TStringlist): integer;

Variante 2:
Andererseits kann ich auch eine function schreiben, nur Strings entgegen nehmen kann

Delphi-Quellcode:

function MYCLASS.Add(value:String): integer;

und würde die Daten in einer Schleife im Hauptprogramm (nicht in MYCLASS) übergeben.

z.B.

Delphi-Quellcode:

while (ListView1.Items.Count)>i do
  begin;
    Class.Add(ListView1.Items.Item[i].Caption)
    inc(i);
  end;

Variante 3:

das gleiche wie Variante 2 und Variante 1 zusammen, jedoch wird die Schleife in die Klasse MYCLASS ausgelagert.

Mein Favorit ist die Variante 2.Der Vorteil der Variante 2 ist, ich kann die Fehlerbehandlung in mein Hauptprogramm auslagern und kann damit auch bei einzelnen Fehler direkt reagieren. Weiterhin habe ich die Möglichkeit, das gerade bei langwierigen Operationen per

Delphi-Quellcode:

application.ProcessMessages

die Applikation nicht wie abgestützt aussieht und noch reagiert. Durch das Auslagern der Fehlerbehandlung ist der Code zudem wiederverwendbar.

Was haltet Ihr davon?

[thkerkmann]

Hi,

bezogen auf Deine Klasse wäre es guter Programmierstil, beide Möglichkeiten zu implementieren.
Welche Du dann im Hauptprogramm benutzt hängt dann von den Datenstrukturen dort ab.
Wenn aber andere Leute Deine Klasse auch noch benutzen wollen, können Sie frei entscheiden was für sie am besten ist.
Dadurch wird deine Klasse eben universeller verwendbar.
Der Einsatz von Application.ProcessMessages innerhalb der Klasse ist nicht zu empfehlen.
Je nach Einsatzgebiet kann das Hauptprogramm dadurch ganz schön durcheinander geraten.

Gruss

Thomas.

[Elvis]

Einmal ein einzelnes Item mit Add reinwerfen und möglicherweise zusätzlich einen Container mit AddRange reinwerfen. ;)
In AddRange kann man dann solche Optimierungen wie BeginUpdate/EndUppdate einbauen...

[ozz]

Danke thkerkmann und Elvis.

@Elvis
Im Prinzip habe ich dich verstanden, jedoch bei BeginUpdate/EndUppdate hängt es. :gruebel:
Hast du mir auf die Sprünge helfen?

Danke!

[Luckie]

Dann schlag die Begriffe mal in der Delphi Hilfe nach, dann verstehst du, was gemeint ist.

[Robert Marquardt]

Statt TStringList sollte man TStrings nehmen. Damit hat man dann die Auswahl unter vielen abgeleiteten Klassen die man uebergeben kann. TStringList ist natuerlich mit dabei, aber es gehen dann auch mehrere Klassen die in der Ableitungshierarchie neben TStringList stehen.

Wer ProcessMessages benutzt hat schon verloren wenn es um Programmierstil geht.
Ein Thread sollte her.

[jbg]

Zitat:

Zitat von Robert Marquardt

Wer ProcessMessages benutzt hat schon verloren wenn es um Programmierstil geht.

Warum? Ist doch toll, wenn der Benutzer die Daten löschen kann, während sie verarbeitet werden :mrgreen:

[Bernhard Geyer]

Zitat:

Zitat von Robert Marquardt

Wer ProcessMessages benutzt hat schon verloren wenn es um Programmierstil geht.
Ein Thread sollte her.

So krass würde ich das nicht sagen. Manchmal steht der Mehraufwand in keinem Verhältnis zu Oberfläche "absichern" + ProcessMessage. Es ist jedoch problematisch wenn ProcessMessage in einer Klasse/Funktion verwendet wird und dann der Aufruf absolut nicht weis das die Funktion "unterbrechend" arbeitet und damit ein mehrfacher Aufruf der Funktion möglich wäre.

[Robert Marquardt]

Der Extraaufwand lohnt sich immer!

Ich habe letztens mal zwei Klassen geschrieben. Eine steuert bei unserem IO-Warrior 32x8 echte LEDs an die andere implementiert ein Game of Life und gibt es mit Hilfe der anderen Klasse aus.
Jetzt habe ich die Ausgabeklasse fuer ein anderes Geraet umgeschrieben und das Game of Life laeuft jetzt mit 320x240. Alles in weniger als einer halben Stunde geaendert.

[sakura]

Zitat:

Zitat von Robert Marquardt

Der Extraaufwand lohnt sich immer!

Ich weiß nicht warum, aber mit solchen Absolutismen habe ich immer Probleme ;) Es gibt Programme, bei welchen es nur um eine Aufgabe (z.B. Datenkonvertierung) geht und ein "ruhiges" Einsetzen von Application.ProcessMessages ist da einfach effizienter und sinnvoller als gleich einen Thread dafür zu errichten.

...:cat:...