Weniger zur Technik, sondern zur Philosophie:
Hier eine Variante ohne diese Abhängigkeiten und Überflüssiges (z.B. IWaitCursor
) und vor allem auch kaskadierbar
Kritik soll es nicht sein (ist ja technisch einwandfrei, Daumen hoch auf für das
[weak]
!), aber ich finde grade bei Dingen wie etwas, das in seinem Konstruktor und Destruktor aktiv das Gesamtbild des Systems verändert es nicht angebracht, das automatisch ablaufen zu lassen wenn es
out of scope geht.
Habe ich ein
Delphi-Quellcode:
procedure aufwändigeAufgabe();
begin
// Schritt 1
TWaitCursor.Show();
doStuff();
doEvenMoreStuff();
// Schritt 2
transferMoney();
logStuff();
end;
und jemand spaltet mir das, ohne es besser zu wissen in
Delphi-Quellcode:
procedure aufwändigeAufgabe();
begin
schritt1();
schritt2();
end;
procedure schritt1();
begin
TWaitCursor.Show();
doStuff();
doEvenMoreStuff();
end;
[...]
auf, ist das Stundenglas nur noch für Schritt 1 zu sehen. Ja, hätte Refactor-Man es richtig gemacht, hätte er es in
aufwändigeAufgabe()
gelassen. Aber ich finde den Fehler kann man zu einfach machen.
Ich packe gerne Dinge wie eine lokale
TStringList
in eine interface-referenzierte Tonne um mir den try..finally-Block für das Aufräumen zu sparen, aber grade im Fall mit dem Cursor wäre mein persönlicher Geschmack wirklich weiterhin ein waschechter try..finally-Block. Da sieht man auch auf den ersten Blick was man hat- Ohne zu wissen, was sich hinter den
TWaitCursor
-Kulissen abspielt.