Container-Klassen in Delphi

[Luckie]

Container-Klassen in Delphi
Verwalten von Objekten mit Hilfe von Container-Klassen am Beispiel eines Memory Spieles

In diesem Tutorial geht es darum, wie man Objekte mit einer Container-Klasse verwalten kann. Demonstriert wird das ganze an Hand der Implementierung eines einfachen Memory Spieles.

Bitte guckt es euch mal an und sagt mir, wo man noch was ergänzen oder verbessern könnte.

[Daniel]

Moin Michael,

bei Deinem C#-Beispiel:

Zitat:

Auffällig ist hier nur, wenn man mal von der C# spezifischen Syntax absieht, dass es keinen
Destruktor gibt und nirgends etwas frei gegeben wird.

Also ich finde, dass am C#-Sharp-Code viel mehr auffällt, dass Du Generics benutzt und damit schon direkt eine typsichere Liste am Wickel hast. Deine Add- und Remove-Methoden werden damit überflüssig, da die Typsicherheit durch die deklaration gewährleistet ist. Die gesamte Mantel-Klasse könnte man also aus dem Beipsiel entfernen - oder man gibt ihr eine eigenständige Funktion. Aber als Wrapper alleine ist sie in diesem Beispiel nicht mehr nötig.

[Luckie]

Ich weiß. Aber zum einem wollte ich das Beispiel möglichst dem Delphi Beispiel ähnlich halten, damit man leichter vergleichen kann und zum anderen könnte man den Wrapper brauchen, wenn man der Container-Klasse noch einige Features mitgeben will. Aber natürlich hast du recht, wenn du sagst, dass sie in diesem Beispeil eigentlich überflüssig ist. Das kann ich ja noch im Tutorial ergänzen.

[Daniel]

Dann lass doch einfach die Verwendung der Generics weg und nimm' ne normale Liste. Dann kannst Du ja im Kommentar erwähnen, dass der .NET-typische Weg eigentlich die Verwendung der Generics wäre, Du hier aber, um die Parallelen zu zeigen, auf eine klassische Liste zurückgegrifefn hast.

[Khabarakh]

Auch sollte der Wrapper auf jeden Fall IList<T> implementieren, wodurch der Code aber schnell mal doppelt so lang wie bisher werden könnte ;) .
Es ist einfach so, dass die BCL einem in den allermeisten Fällen keinen Grund gibt, einen eigenen Wrapper zu schreiben. Brauche ich eine strunzdumme Liste, nehme ich List<T>, brauche ich eigene Logik, erbe ich von Collection<T>. Der Blick über den Tellerrand ist eine schöne Idee, aber zeigt er eben nur die Syntax von C# und das Vorhandensein eines GC und nicht das Eigentliche: Wie ein .Net-Entwickler das Problem lösen würde.

Entweder würde ich mir noch irgendeine für Personen-Objekte vernünftige Prüfung vor dem Einfügen in die Liste ausdenken[*] und dann das Ableiten von Collection<Person>, Überschreiben von InsertItems und schließlich auch die Benutzung der entstandenen Klasse zeigen, oder, wie du schon sagtest, das Beispiel stehen lassen und den Text noch etwas weiter ausführen (ArrayList würde ich eher nicht verwenden, denn das hat dann wirklich nicht mehr viel mit .Net-Code zu tun), wobei du dann noch zwei Kleinigkeiten ändern könntest:
Den Cast im Getter kannst du weglassen, denn gerade dafür hast du ja die generische innere Liste, ebenso die Namespace-Angabe von IEnumerator<T>, die eher verwirren dürfte und die du bei List<T> ja auch nicht verwendet hast.
[*]Dir fallen bestimmt schönere Beispiele als "eine Liste, die nur Personen annimmt, deren Nachname mit A anfängt" ein :zwinker: .

[Luckie]

Das habe ich mir fast gedacht, das dieser Teil noch nicht ganz optimal ist. aber ich mache selber erst meine ersten ernsthaften gehversuche in C# (zwangsweise aus beruflichen Gründen).Ich werde ihn dann noch mal etwas überarbeiten. Danke für die Hinweise.

[Elvis]

Zitat:

Zitat von Khabarakh

Auch sollte der Wrapper auf jeden Fall IList<T> implementieren, wodurch der Code aber schnell mal doppelt so lang wie bisher werden könnte ;) .

Naja, es gäbe da die Option das Tellerranddingsens als .Net im Allgemeinen aufzufassen und dann gäbe es eine weitere Sprache, die genau das vereinfacht.
Hier mal Pseudo code, wie eine Liste aussehen kann, deren Elementtyp zwar generisch ist, aber T muss mindestens Person oder ein Nachfahre sein und einen öffentlichen, parameterlosen Konstruktor besitzen:

Delphi-Quellcode:

type  
  PersonList<T> = public class(IList<T>)
    where T is Person, T has constructor;
  public
    method AddNew : T;
    method Add(item : T);
    property Count : Integer
      read Innerlist.Count;
    property Item[index : Integer] : T
      read  InnerList[index]
      write InnerList[index]; default;
  protected
    property InnerList : List<T> := new List<T>(); readonly;
      implements IList<T>; // *plopp*, schon implementiert...
  end;

implementation

method PersonList<T>.Add(item : T); 
begin 
  Innerlist.Add(item); 
end;

method PersonList<T>.AddNew : T;
begin
  result := new T();
  Add(result);
end;

OK, man hätte gleich von List<T> ableiten können... *g*

[xZise]

Hi Luckie,
nettes Tutorial (irgendwo her kenne ich das, aber es soll erst 4 Tage alt sein :gruebel: ).
Eine Sache fiel mir auf, und ja ich weiß ich bin kleinlich, aber dennoch finde ich, dass du es wissen solltest :)
Und zwar schreibst du in 3.:

Zitat:

Zentrale Methode ist die Methode

Delphi-Quellcode:

procedure Click(Sender: TObject); reintroduce;!

1. Die Zentrale Methode ist die Methode.
   Ich hätte da sowas geschrieben: Das zentrale Ereignis ist die "OnClick"-Methode.
2. Ist dein "!" in die Codezeile gerutscht :)

Eine Frage dazu habe ich noch:
Warum nicht von TList erben, und dann die Add... Methoden mit neuen Parametern überschreiben?

MfG
xZise

PS: Für ein Programm habe ich die Methode schon erfolgreich angewendet! Das funktioniert sehr gut, und ist richtig cool :)

[Khabarakh]

Zitat:

Zitat von xZise

Warum nicht von TList erben, und dann die Add... Methoden mit neuen Parametern überschreiben?

Wie willst du eine statische Methode überschreiben, noch dazu mit anderen Parametern :stupid: ? Und wenn du Add nur verdeckst/überlädst, hast du am Ende alles Mögliche, aber auf keinen Fall eine typsichere Liste.

@Elvis: Wenn ich das nächtse Mal vor dem Problem stehe, einen Wrapper ohne eigene Logik schreiben zu müssen, werde ich dran denken, versprochen *g* .

[Luckie]

Zitat:

Zitat von Khabarakh

ebenso die Namespace-Angabe von IEnumerator<T>, die eher verwirren dürfte und die du bei List<T> ja auch nicht verwendet hast.

Aber die brauche ich doch für das foreach Konstrukt:

Code:

// benötigt für foreach
        public System.Collections.Generic.IEnumerator<Person> GetEnumerator()
        {
            return innerList.GetEnumerator();
        }

und irgendwie, muss ich ja den Rückgabetyp festlegen.

[OregonGhost]

Du benötigst auch beim Rückgabewert keinen vollqualifizierten Typnamen, wenn der entsprechende Namespace oder Typ importiert wurde, was wohl der Fall ist, wenn du List<T> ohne Namespace-Angabe verwendest.

[Elvis]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Khabarakh

ebenso die Namespace-Angabe von IEnumerator<T>, die eher verwirren dürfte und die du bei List<T> ja auch nicht verwendet hast.

Aber die brauche ich doch für das foreach Konstrukt:

Dafür solltest du IEnumerable<T> implementieren.
Denn so wie du es jetzt hast, hast du nur eine öffentliche Methode GetEnumerator und vertraust darauf, dass der Compiler anhand dieses Namens und des Rückgabewertes entscheidungen trifft. Aber ohne IEnumerable<T> gibt es kein LINQ und viele andere Dinge gehen auch nicht.
Eine Containerklasse sollte in .net alle Standardinterfaces implementieren, die auf sie zutreffen.
Bei dir wäre das IList<T>, welches ICollection<T> und IEnumerable<T> mitbringt.

[Luckie]

Zitat:

Zitat von Elvis

Dafür solltest du IEnumerable<T> implementieren.
Denn so wie du es jetzt hast, hast du nur eine öffentliche Methode GetEnumerator und vertraust darauf, dass der Compiler anhand dieses Namens und des Rückgabewertes entscheidungen trifft. Aber ohne IEnumerable<T> gibt es kein LINQ und viele andere Dinge gehen auch nicht.
Eine Containerklasse sollte in .net alle Standardinterfaces implementieren, die auf sie zutreffen.
Bei dir wäre das IList<T>, welches ICollection<T> und IEnumerable<T> mitbringt.

Da stehe ich jetzt ehrlich gesagt etwas auf dem Schlauch. :gruebel:

[Elvis]

Zitat:

Zitat von Luckie

Da stehe ich jetzt ehrlich gesagt etwas auf dem Schlauch. :gruebel:

IEnumerable ist das Basisinterface für alles worüber man einen for-each machen kann.
Also für alle Datencontainer.
IEnumerable<T> ist eine Spezialisierung für einen bestimmten Itemtypen.
"LINQ over Objects" basiert auf IEnumerable<T>, genau wie viele Methoden von vielen Hunderten von Klassen mit IEnumerable<T> umgehen können.
Es nicht zu implemetnieren würde heißen, dass deine Containerklasse nur so wie in Delphi wäre: Eine weitere Klasse. Mit der Implementierung ist sie eine richtige Containerklasse, auf die du Abfragen machen kannst, die du mit einem Call an eine andere Liste anhängen kannst,...

Mit meinem Beispiel oben wäre folgende LINQ-Query möglich:

Delphi-Quellcode:

var persons := new PersonList<Person>();
// irgendws hinzufügen

var personNames := 
  (from   p in persons
   where  not String.IsNullOrEmpty(p.Name)
   select distinct p.Name).ToList();

[Luckie]

Ich habe jetzt eine aktualisierte Fassung im ersten Posting hochgeladen. Die Modifikationen der Klasse, wie sie Elvis vorschlägt sind noch nicht eingearbeitet.

[xZise]

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von xZise

Warum nicht von TList erben, und dann die Add... Methoden mit neuen Parametern überschreiben?

Wie willst du eine statische Methode überschreiben, noch dazu mit anderen Parametern :stupid: ? Und wenn du Add nur verdeckst/überlädst, hast du am Ende alles Mögliche, aber auf keinen Fall eine typsichere Liste.

*pfeif*

Ich sehe gerade, Luckie, dass du fast genauso wie ich es vorgeschlagen habe, hast du es umgesetzt. :mrgreen:

MfG
xZise

[mashutu]

Sorry wenn das jetzt hier leicht OT wird,
aber ich bin soeben ueber den Konstrukt

Delphi-Quellcode:

type  
  PersonList<T> = public class(IList<T>)
    where T is Person, T has constructor;
[...]

gestolpert.
Ich arbeite zwar seit mehr als 20 Jahren mit Pascal, aber diese Syntax ist mir neu und latuernich moechte ich wissen, was das ist und wie man es verwenden kann. Falls jemand einen Link zu einem Tutorial hat, waere ich dankbar.

[Luckie]

Das ist ja auch kein Pascal, sondern C#.

[Khabarakh]

Nope, das ist Roberts Chrome-Schnipsel :zwinker: .

@mashutu: Chrome ist ein Pascal-Dialekt für .Net. Was du dort siehst, ist ein .Net-Feature namens Generics, die vor allem von Java bekannt sind. Auch FreePascal, C++, Ada, ... bieten so etwas (Ähnliches).
Kurz umrissen kannst du beim Benutzen der Klasse den Typparameter T durch einen beliebigen Typ ersetzen (wobei da noch die Constraints eine Rolle spielen, die du mitgequotet hast: T muss von Person abgeleitet sein und einen öffentlichen, parameterlosen Konstruktor haben).

Delphi-Quellcode:

var
  list : PersonList<Customer>; // T = Customer (eine von Person abgeleitete Klasse)
begin
  [...]
  list[0].Orders[...]; // Person besitzt keine Eigenschaft Orders, dennoch müssen wir nicht casten, da Item[] ja nicht Person sondern T zurückgibt. Und in unserem Fall ist T = Customer
end;

[mashutu]

Danke an Lucky und Khabarakh fuer die kurze Info und den Link zu Chrome