TStringlist sortieren

[Bernhard Geyer]

Zitat von marabu:

Informatiker lernen, dass man Variablen stets nur für diejenige Superklasse vereinbart, deren Methoden und Eigenschaften man zu nutzen gedenkt. Es handelt sich dabei um eine Spielart von information hiding. Dieses universelle Grundprinzip kennen nicht nur Software Ingenieure ...

Für viele Fälle mag ich dir zustimmen. Aber in diesem konkreten Fall wäre dies nur sinnvoll wenn es u.U. eine globale oder Membervariable wäre und die TStrings-Klasse eine abstrakte Methode Sort hätte.

[Der_Unwissende]

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

[marabu]

Hallo Bernhard,

deinen Beitrag #11 hast du bestimmt geschrieben ohne meinen Beitrag #10 gelesen zu haben - oder?

Freundliche Grüße

[marabu]

Jetzt trifft mich der Schlag - 601 Wörter in 26 Minuten. Danke für diese umfassende und zielgruppengerechte Darstellung, (Un)Wissender.

Freundliche Grüße

[Udontknow]

*BITTE LOESCHEN*

[Bernhard Geyer]

Zitat von marabu:

deinen Beitrag #11 hast du bestimmt geschrieben ohne meinen Beitrag #10 gelesen zu haben - oder?

Genau. #10 hatte ich nicht gelesen.

[Der_Unwissende]

Zitat von marabu:

Jetzt trifft mich der Schlag - 601 Wörter in 26 Minuten. Danke für diese umfassende und zielgruppengerechte Darstellung, (Un)Wissender.

Danke eher Dir, dass Du das Thema angesprochen hast!

Gruß Der (weiterhin) Unwissende

[bernau]

@Der_Unwissende
Das war ausführlich!!! Danke.

@Marabu
Danke für deine Klarstellung



So ist mir das schon klar. Und in vielen Punkten stimme ich mit euch überein.

Vieleicht war das Beispiel des Eingangspost das Irreführende.



Für mich hatte es so ausgesehen, daß der Programmcode von little_budda in einer Procedure vorkommt.

Delphi-Quellcode:

Procedure EineProcedure;
var
  slOutList : tstrings; 
begin 
  slOutList := tstringlist.create(); 
  // Hier wird irgendwas gemacht
  slOutList.free;
end;

Dies wäre für mich nicht sinnvoll. Dort würde ich auf Jeden Fall "slOutList : tstringlist;" deklarieren.

Was anderes ist es, wenn ich eine Stringliste in einer Function als Parameter verwenden möchte. Dort verwende ich natürlich die niedrigst mögliche Klasse.

Delphi-Quellcode:

Procedure EineProcedure(aStrings:TStrings);
begin 
  // Hier wird irgendwas mit aStrings gemacht
end;

Der Function kann ich so alle Objekte übergeben, die von TStrings abgeleitet wurden. DAs macht sinn.

Es macht auch sinn z.B. TStrings statt Tstringlist als Property in einer einer Klasse zu definieren, um der Klasse ein Objekt zu übergeben, welches von TStrings abgeleitet ist um mit diesen Daten weiterzuarbeiten. Aber dann wird es in der Klasse nicht schon instanziert, wie es das Beispiel von little_budda sugeriert.

So ähnlich ist es ja auch bei TImage/TPicture. Dort wird das Bitmap,Image,Metafile,etc auch nicht im constructor von TPicture instanziert, sondern erst beim Zugriff auf das Property Picture.



Gerd