Hi,
erstmal möchte ich hier dem marabu völlig zustimmen.
In kleinen Projekten werden sich die Konsequenzen der Implementierungs-Entscheidungen doch stark in Grenzen halten. Hier arbeiten häufig nur einzelne Personen dran (die den vollen Überblick über alles haben) und Erweitern/Warten wird auch eher selten der Fall sein (insbesondere würde es die selbe Person übernehmen und das wohl eher in kurzem Abstand zur Veröffentlichung).
Zitat von
Hansa:
Gegenbeispiele
für globale Variablen gibts nämlich auch. Beispiel : brauche einen konstanten Wert überall im Programm. Ganz klar : ist eine Konstante. Den Wert kann ich aber trotzdem nicht als CONST deklarieren, weil er vom Einsatzort abhängt und auch geändert werden kann. Der kommt eben aus INI-Datei. Er wird beim Programmstart einmalig gelesen und während der Ausführung des Programmes verwendet. Ich wäre schön blöd, den für jede Form an eine private-Variable zu übergeben oder mich mit Properties oder sonstwie zu verrenken.
Na ja, das Beispiel für globale Variablen finde ich ist nicht wirklich gegeben. Natürlich kann man eine globale Variable anlegen, die irgendwann irgendwie mit dem Wert der Ini gefüllt wird. Aber hier hat man dann doch wieder das Beispiel der völlig falsch gewählten Sichtbarkeit. Hier kann jeder aus einer anderen
Unit diesen Wert als Variable sehen, also auch verändern. Es gibt also weder eine Garantie dafür, dass ich diesen Wert/ diese Variable falsch benutze und den Wert selbst setze, noch kann ich vor dem Lesen sicherstellen, dass der Wert schon geladen wurde. Natürlich kann ich dies im Initialisierungs-Teil der
Unit machen, aber ob das dann eine schöne Lösung ist?
Vorallem lässt sich das ganze (
imho) schlecht modellieren.
Der eigentlich Sinn der
OOP ist es doch letztlich nicht Objekte zu erstellen oder über Klassen zu sprechen. Ich denke eines der wichtigsten Konzepte der
OOP steckt in der Abstraktion. Man kann hier sehr schön abstrakt modellieren und die eigentliche Implementierung bleibt von außen völlig verborgen. Man kennt ebend nur die öffentlichen Schnittstellen und hat aut. austauschbare und wiederverwendbare Teile. Das Wort Teile ist natürlich sehr schwammig, korrekter könnte man hier schon von Komponenten sprechen. Doch dazu möchte ich dann auch gleich sagen, dass eine Komponente (in der Informatik) nichts mit einer bestimmten Vorfahrklasse (z.B. TComponent), nicht mal direkt etwas mit
OOP zu tun hat. Man kann aber
OOP-Sprachen als Komponenten-Modell auffassen, die Klassen als Komponenten und die Objekte als Komponentenexemplar.
Die Vorteile solcher Komponenten sollten dann auch klar sein, man kennt nur ihre Schnittstellen nach außen und kann eine weitere Komponente einfach aus mehreren anderen Komponenten (und etwas Glue-Code) zusammensetzen. Dieses "Lego-Prinzip" ist sehr mächtig, da man hier jede Komponente gegen eine mit gleicher Schnittstelle austauschen kann, ohne dass dies das restliche Programm verändert.
So ist es dann leicht möglich fremde Komponenten (z.B. zugekauftes Know-How/Expertenwissen) einfach in ein Programm zu integrieren. Ist diese Komponente noch nicht verfügbar, steht aber die Schnittstelle fest, kann man z.B. mit einer Dummy-Komponente (gleiche Schnittstelle aber nur Dummy-Funktionalität) schon am restlichen Programm arbeiten und diesen Dummy später durch die echte Implementierung ersetzen.
Ok, bin etwas vom eigentlichen Thema abgeschweift, was? Na ja, wie bereits gesagt, der marabu hat das eigentlich Wichtige (
imho) schon sehr viel besser auf den Punkt gebracht.
Gruß Der Unwissende