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 .

[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 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 ).
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
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 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 ? 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 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.