Zitat von
bernau:
Ich denke, wenn ich in einer Procedure ein Object deklariere, dann verwende ich als Variable auch den Type den ich brauche. Un anscheinend gedenkt little_budda ja die Functionen von TStringlist zu verwenden. Warum dann nicht die Variable als TStringlist deklarieren?
Hi,
dass ganze solltest Du nicht nur auf dieses Beispiel beziehen (hier wird schließlich die Methode sort benötigt und eine entsprechende Superklasse, eben TStringlist, sollte vereinbart werden).
Aber im Allgemeinen verwendet man gerne abstrakte Klassen / Interfaces (als Superklasse), da man hier leicht die Implementierung austauschen kann. Typisches Beispiel wäre hier TStrings oder auch TStream. Beides abstrakte Klassen, es sind nur die Methodensignaturen sichtbar, die Implementierung existiert nur in den Nachkommen.
Wenn Du jetzt einen Stream benötigst, dann weißt Du, dass der eine Methode zum Lesen und Schreiben hat, wie aber genau die Funktionieren (ob aus einer Datei, einem Stream, einem String, ... gelesen wird ist für dich transparent). Nimm jetzt z.B. ein Kompressions-Bibliothek, die komprimiert einfach einen Stream. Was muss die dafür wissen? Na ja, wie sie die Daten aus dem Stream bekommt, was mit der Lese-Methode schon erfüllt ist. An eine Methode, die hier also nur einen Stream erwartet kannst Du jetzt sowohl Instanzen von TMemoryStream, TFileStream, THandleStream, ... (auch eigene Nachkommen) übergeben, wichtig ist eben nur, dass die die abstrakten Methoden von TStream implementieren.
Jetzt kannst Du aber auch gleich die Kompression abstrakt aufbauen, indem du einfach eine abstrakte Basis erstellst, die ein TStream Objekt bekommt und komprimiert. Hier kann dann wiederum für jeden Kompressionsalgorithmus ein eigener Nachfahre geschaffen werden, nach aussen verhalten die sich aber alle gleich.
Baust Du also so dein Programm zusammen, hast Du den Vorteil, dass die Implementierung an jeder Stelle immer leicht ausgetauscht werden kann, ohne dass sich etwas an der Programmlogik ändert.
Jetzt kann man natürlich argumentieren, dass man aber auch selten die Implementierung ändert, doch das stimmt i.d.R. nicht. Neben Fehlerkorrekturen oder Verbesserungen der Performance (z.B. TStringList durch THashedStringList ersetzen, beschleunigt das Suchen) oder anderen Verhaltens sollte man hier unbedingt die Teamarbeit betrachten. Große Projekte können natürlich nicht von nur einer Person bearbeitet werden. Typischer Weise wird man also das Gesamtproblem in kleinere Teile zerlegen, die dann von unterschiedlichen Teams/Personen gelöst werden können. Jetzt gibt es aber zwei wichtige Probleme, einerseits müssen die Teillösungen irgendwann zusammengefügt werden, anderseits bestehen aber auch häufig Abhängigkeiten. Z.B. wenn man eine Datei laden/speichern können soll, so muss bekannt sein, wie ein Datum im Speicher liegt. Hier ist es also wichtig, dass nicht jedes Team/jede Person eine eigene Vorstellung hat (und man erst beim Zusammensetzen merkt, dass die nicht kompatibel sind).
Natürlich kann man warten, bis alle Abhängigkeiten aufgelöst sind, bevor man ein Problem löst, dann würde es aber im schlimmsten Fall dazu kommen, dass auch eine Person alles machen kann (keine Parallelen Arbeiten möglich). Beim Parallelen Arbeiten hat man dann wiederum das Problem, dass einige Probleme schneller gelöst werden können als andere. Jede Menge Probleme.
Die können aber alle mit der Verwendung von abstrakten Datentypen erschlagen werden. Legt man verbindliche Schnittstellen (eben nur die Signatur der öffentlichen Methoden) fest, so muss jede Implementierung diese erfüllen. Jede Gruppe kann sich dann auf diese Schnittstellen beziehen, ohne wirklich zu wissen wie und wann die eigentliche Implementierung der externen (nicht zur Gruppe gehörigen) Datentypen erfolgt.
Viele der Vorteile kann man auch gleich bei Delphi bewundern, z.B. die Möglichkeit, dass ein TImage-Objekt alle TPicture-Nachkommen anzeigen kann, ohne dass diese schon bekannt waren, also TImage geschrieben wurde. Schreibt z.B. jmd. einen TPicture-Nachfahren für Tiff-Files, so könnte man diese einfach in einem TImage anzeigen, da hier eine der abstrakten Methoden für das Zeichnen auf einen Canvas zuständig ist, der halt übergeben wird. Auch beim Drucken sieht es ähnlich aus, es wird einfach nur auf einen Canvas gezeichnet, ob es nun der Canvas eines Druckers, einer Bitmap oder von sonst was ist bleibt völlig transparent (für Methoden wie BitBlt)
Gruß Der Unwissende