Überwachen von Objekteigenschaften

[Luckie]

Zitat:

Zitat von noisy_master (Beitrag 1064729)

Hast recht ist zwar kein gutes Design, manchmal muss es aber halt sein.

Es gibt keinen guten Grund für schlechtes Design. Wenn man aus Zeitdruck mal schlechten Code schreiben muss OK, aber das Design macht man ja schon vorher.

[DeddyH]

Wenn man Projekte von anderen übernimmt, muss man wohl oder übel auch das ggf. miese Design übernehmen, es sei denn, man hat sehr viel Zeit (wer hat die schon?).

[Luckie]

Das ist was anderes. Aber offensichtlich handelt es sich um sein eigenes Projekt. Aber auch Refactoring kann Zeit sparen. Ich habe mal Code vom Kollegen bekommen, den er so runtergetippt hatte. Dieser Code sollte jetzt erweitert werden. Ich glaube es waren sechs Stunden veranschlagt. Ohne Refactoring hätte ich das in den sechs Stunden nicht geschafft. Weil keine Struktur drin war. Und beim verstehen ist das Refactoring fast von alleine gegangen. Vom ursprünglichen Code ist eigentlich nur der rein funktionale Code übrig geblieben.

[shmia]

Zitat:

Zitat von stahli (Beitrag 1064328)

@shima
Häng Dich doch mal nicht an dem Button auf...
Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden.

Ok, es gibt Klassen, Properties, Proceduren und Funktionen in die man nicht hineindebuggen kann; also kurz gesagt Code, der nicht unter der eigenen vollständigen Kontrolle steht.
Dazu gehört z.B. die Windows API, ActiveX und Komponenten aus der VCL.
Ja, man kann mit Debug-DCUs kompilieren aber es handelt sich doch um fremden Code.

Im Laufe der Jahre habe ich gelernt mit diesem "Fremdcode" umzugehen.
Falls nötig baue ich um diesen Fremdcode eine Schicht, die meistens aber nur hauchdünn ist.
Es ist wichtig zu erkennen, wann man die Schicht braucht und wann nicht.
Die Schicht kann manchmal auch nur eine Funktion sein, die ein Argument 1 zu 1 weiterleitet.

Delphi-Quellcode:

Beispiel
procedure TForm1.ShowError(const msg:string);
begin
  ShowMessage(msg);
  // oder
  // Statusbar1.SimpleText := msg;
end;

Diese Schicht ist sehr dünn, aber ich kann einen Breakpoint setzen oder die Fehlermeldung auf eine andere Weise anzeigen.

Für den Zugriff auf Komponenten habe ich meistens keine Zwischenschicht.
Nur falls nötig oder falls ein Spareffekt (z.B. mehrere Buttons auf einen Rutsch dis/enablen) eintritt würde ich eine Procedure/Funktion als Zwischenschicht einführen.

Ganz anderst sieht das mit Handles und Zeigern der Windows API aus.
Hier kapsele ich grundsätzlich immer mit einer Klasse, Procedure oder Funktion.
Stellt euch vor es gäbe die Klassen TFont, TCanvas, TPen und TBrush nicht.
Was wäre das für eine Qual irgendetwas zu zeichnen.

Ähnlich sieht das bei Zeigern und Strukturen aus der Windows API aus.
Ich würde z.B. niemals die Windows API-Funktion GetComputerName() direkt in meiner Anwendung aufrufen.
Nein, dieser Aufrauf braucht eine kleine Zwischenschicht:

Delphi-Quellcode:

function GetLocalComputerName: string;
var
  Count: DWORD;
begin
  Count := MAX_COMPUTERNAME_LENGTH + 1;
  SetLength(Result, Count);
  if GetComputerName(PChar(Result), Count) then
    StrResetLength(Result)
  else
    Result := '';
end;

Ich würde auch nie auf die Idee kommen meine Anwendung direkt mit WinSock-Funktionen (socket(),bind(),listen(),..) oder Funktionen für die serielle Schnittstelle reden zu lassen.
Hier braucht es unbedingt eine Klasse, die den Zugriff kapselt.
Automatisch habe ich dadurch Code auf den ich Breakpoints setzen kann.

Fazit: um Code, der nicht unter der eigenen Kontrolle steht sollte man (bei Bedarf) eine Zugriffsschicht legen.
Die dünnstmögliche Schicht ist die 1:1 Weiterleitung einer Funktion/Procedure