TStringList als Result einer Funktion

[Sir Rufo]

Nur so aus Spass (dann sind doch alle glücklich)

Delphi-Quellcode:

procedure FillWithAnimals( const Dest: TStrings; Append : Boolean = False );
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    if not Append then
      Dest.Clear;
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

[himitsu]

Zitat von Sir Rufo:

Nur so aus Spass (dann sind doch alle glücklich)

Ähhhhhhhhhhhhhhhhhhhhhhhhhhh....

Ne


Append wird ja immer gemacht, aber das Clear wird gesteuert.

Delphi-Quellcode:

procedure FillWithAnimals(Dest: TStrings; Clear: Boolean=False); 
// oder doch AppendAnimals (ohne Denglisch), ist nun auch egal, wobei es ja dennoch immer Append macht

Ja, Const ist schon richtig, da die Referenz wirklich nicht verändert wird, aber da man was in der Klasse verändert (hinzufügt), finde ich es imho etwas "verwirrend".
Wobei var natückich "logisch" gesehn eindeutiger wäre, aber in Bezug auf den Zeiger ja vollkommen falsch ... dann doch lieber ohne.

Mir würde es ja gefallen, wenn man für Klassen/Zeigertypen dennoch ein IN und OUT angeben könnte, als Info für den Entwickler. (wobei man das ja im HelpInsigt/DokuInsigt machen könnte, wenn man es da einführen täte)

Und hier ist das Problem mit der typisierung besonders groß.
> mit VAR könnte man nur genau diesen Typen, als übergebene Variable verwenden und was drin ist, ist egal
> bei TStringList kann man nur TStringList und Nachfahren reingeben, obwohl intern nur Methoden des TStrings verwendet werden
> mit TStrings wäre auch ein Memo.Lines möglich

[Sir Rufo]

Eventuell ist mein englisch eingerostet, aber bei Fill erwarte ich, dass die Liste gefüllt und eben nicht aufgefüllt wird (wäre dann ja Fillup). Darum der Parameter Append mit default False .

Es kommt also nicht darauf an, was gemacht wird, sondern was der Name nahelegt und logisch ist.

Deine Funktion müsste also logischerweise procedure AppendAnimals( Dest: TStrings; Clear: Boolean=False ); heissen.

[DeddyH]

Man kann auch einen eigenen Aufzählungstyp samt Parameter dieses Typs definieren, der besagt, ob vorne oder hinten angehängt oder die Liste vorher gelöscht werden soll. Damit sollten dann wirklich alle zufrieden sein.

[Dejan Vu]

Oder man schreibt einfach für jeden Anwendungsfall eine Methode.

Delphi-Quellcode:

Type
  ITiereUndListenDingenskirchen = interface
    Procedure InsertAtFront (aDestination : TStrings); 
    Procedure InsertAtEnd (aDestination : TStrings); 
    Procedure InsertAt (aDestination : TStrings; aIndex : Integer);
    Procedure Replace (aDestination : TStrings); 
    ...

Wobei man die beiden ersten Methoden durch die dritte abbilden kann.

Um die Verwirrung zu maximieren gibt es auch noch den Ansatz, das eine API nur die Elementaroperationen bereit stellen sollte. Wenn ich also eine Liste löschen, und Tiere an beliebiger Stelle in der Liste einfügen kann, dann würde nach diesem Ansatz die 'Append'-Methode mit dem 'Clear'-Parameter nicht erlaubt sein. Und dann wäre das Interface vielleicht auf eine Methode beschränkt.

Delphi-Quellcode:

Type
  ITiereUndListenDingenskirchen = interface
    Procedure InsertAt (aDestination : TStrings; aIndex : Integer);
...

Zum Namen: Append/Fill past schon. 'Fill up' bezeichnet eher das 'voll machen'. Und voll ist die Liste hinterher ja nicht, sondern nur voller (Äh, wobei 'voller' widerum die Steigerung von 'voll' ist, rein grammatikalisch, ).

[Jumpy]

Ich les mich gereade ein bißchgen durch CleanCode und da gibt es ja ein ganzes Kapitel über Namensgebung von Funktionen, wo u.a. gesagt wird das so ein Name immer mal wieder verändert wird, bis er endlich das aussagt, was der Entwickler mit der Funktion bezweckt, bzw. bis es ihm gefällt.

Danke euch kann ich mir nun nachvollziehen was gemeint ist.

Allerdings habt ihr mir auch schön das Sprichwort: "Zu viele Köche verderben den Brei" aufgezeigt.

[Dejan Vu]

Zitat von Jumpy:

Allerdings habt ihr mir auch schön das Sprichwort: "Zu viele Köche verderben den Brei" aufgezeigt.

Richtig heißt es: Zu viele Entwickler verderben den Code.