Vermeiden von globalen Variablen

[jfheins]

Zitat:

P.S.: Zusammenfassend kann man vllt. sagen, dass meine "Probleme" neben meiner fehlender Erfahrung auch daher kommen, dass ich mich nicht entscheiden kann, ob ich meine Klasse allgemein halten möchte oder spezieller machen möchte. Ist sie allgemein, dann kann ich die Klasse für viele verschiedene Anwendungen verwenden, dafür erledigt die Klasse wenig Arbeit für mich. Implementiere ich die Klasse hingegen eher spezieller, dann bin ich bei der Verwendung stärker eingeschränkt, aber dafür erledigt die Klasse schon fast alles für mich.

Tendenziell würde ich (aus Erfahrung) sagen: Stelle deine aktuellen Anforderungen zusammen, und dann mach' die Klassen eher spezieller. Oft kommt man dann an Punkte, bei denen man die Klasse etwas allgemeiner machen könnte, "falls es dann irgendwann doch erweitert wird". Mach' das nicht, denn das passiert fast nie. Zumindest nicht in dem Bereich, den du vorher antizipierst

Klar, deine Anforderungen werden sich ändern. Aber meistens sind das dann inkrementelle Änderungen (xyz soll hier ne Spezialbehandlung bekommen, also ein Feature wie "Wenn jemand Freitag den 13. im Kalender auswählt, soll hier ein roter Warnhinweis erscheinen") und nicht solche Sachen wie "Wir möchten eine Datenbank in der man in einem bestimmten Format Warnungsregeln für beliebige Kalendertage definieren kann." - so eine Anforderung ist meistens früh bekannt.

Und wenn du vorzeitig "universell einsetzbaren" Code schreibst, dann sind in deiner Anwendung viele Stellen, in denen du dann wieder einen Spezialfall bauen musst. An der Stelle sieht das dann umständlich aus.

Wenn du etwas vielleicht in anderen Projekten auch mal brauchen kannst, dann programmiere das erst mal so, dass es aktuell passt. Für das andere Projekt kannst du ja die Klasse kopieren und erweitern (wenn du genau weißt, was für eine Erweiterung du jetzt brauchst).

[Jumpy]

Delphi-Quellcode:

if obj.Color = selectedPnlColor then obj.Color := defaultPnlColor
else obj.Color := selectedPnlColor;

Dies sieht ja so aus, als ob du über die Panel-Farbe feststellst, ob eine Datei (für die ja das Panel steht) selektiert ist oder nicht. Hier in der DP wird dir sicher noch sehr oft gepredigt (nicht negativ gemeint) werden, dass es sinnvoll ist, die Logik von der Darstellung zu trennen. Hier könnte das so aussehen, das du unabh. von der GUI eine Liste von Klassen hast, jede steht für eine Datei und in der Klasse könnte es eine Eigenschaft Selected geben. Oder du hast eine Liste aller Klassen/Dateien und eine in der die selektierten Klassen/Dateien stehen.
Wird nun in der GUI geklickt schaust du welche Datei/Klasse dies betrifft. Schaust ob sie bereits selektiert ist oder nicht und änderst diesen Zustand entsprechend.
Anschließend wird die GUI "refreshed".

[Sir Rufo]

@Jumpy & TE

Gerade in Bezug auf die Controls wird hier explizit gepredigt, dass diese Controls zur Darstellung eines Status sehr wohl geeignet sind aber eben nicht um den Status-Wert dort abzulesen bzw. als Status-Speicher zu missbrauchen.

Daten präsentieren: Ja
Daten speichern: Nein

Grund:

Die Präsentation ist immer eine Interpretation von Daten. Um von dem interpretierten und präsentierten Wert wieder auf den Ursprungswert zu kommen ist durch die Brust ins Auge, aufwändig und somit auch extrem fehleranfällig.

Eine Liste mit den echten Informationen und diese Liste einfach in den Controls abbilden ist erheblich einfacher, als von dem Control wieder die richtigen Daten heraus zu interpretieren.