b2aat6n

Listing 8
Auf einen leeren Stack testen.
[Test]
public void Enthaelt_nach_der_Entnahme_des_top_Elementes_keine_weiteren_Elemente()
{
sut.Pop();
Assert.That(sut.top, Is.Null);
}
Listing 9
Mehrere Push-Aufrufe.
[Test]
public void Macht_das_naechste_uebergebene_Element_zum_top_Element() {
sut.Push("b");
Assert.That(sut.top.Data, Is.EqualTo("b"));
}
[Test]
public void Legt_das_vorhandene_Element_bei_Uebergabe_eines_weiteren_unter_dieses() {
sut.Push("b");
Assert.That(sut.top.Next.Data, Is.EqualTo("a"));
}
in einem ersten Test geprüft werden, ob
dieses Element bei Aufruf der Pop-Methode
zurückgegeben wird, siehe Listing 7.
Nun kann überprüft werden, ob der
Stack denn nach dem Pop auch wieder leer
ist, siehe Listing 8. Und jetzt hilft alles
nichts, wir müssen uns mit mehr als einem
Push befassen. Dabei kommt es darauf an,
das neue Element vor das bisherige top-
Element einzuordnen. Dazu muss der top-
Zeiger geändert werden sowie der Next-
Zeiger des top-Elements. Listing 9 zeigt die
entsprechenden Tests.
Daraus ergibt sich dann die fertige Implementierung
des Stacks wie in Listing 10.
Reflexion
Die testgetriebene Vorgehensweise hat mir
keine großen Probleme bereitet. Das lag
zum Großteil daran, dass ich meine Skizze
zur Hand hatte. So konnte ich bei Fragen
sofort nachsehen, wie die top- und Next-
Zeiger jeweils aussehen müssen. Und dadurch,
dass die Tests auf die Interna zugreifen
können, musste ich nicht schon für den
ersten Test gleich zwei Methoden implementieren.
Das ist ein großer Vorteil, der
bei einem so kleinen Beispiel wie einem
Stack möglicherweise nicht so deutlich
wird. Ich habe diesen Effekt jedoch schon
in einigen Fällen als vorteilhaft empfunden,
bei denen es um den internen Zustand
von Klassen ging. Immer da, wo
mehrere Methoden auf einem internen Zustand
arbeiten, kann es sich lohnen, den
Zustand für die Tests sichtbar zu machen,
um bei der Implementierung Methode für
Methode vorgehen zu können.
Queue
Bei der Warteschlange bin ich so verfahren
wie schon beim Stack: Ich habe mir überlegt,
wie man eineWarteschlange in einer Datenstruktur
darstellen kann. Meine Überlegung
hier: Bei einer Warteschlange sollte es offensichtlich
zwei Zeiger geben, die jeweils auf
ein Element verweisen. Zum einen auf das
zuletzt eingefügte Element, um dort bei der
Enqueue-Methode ein weiteres Element ergänzen
zu können, sowie einen Zeiger auf
das nächste zu entnehmende Element für
die Dequeue-Methode. In meiner ersten
Skizze malte ich also das erste und letzte
Element einer Warteschlange und verwies
darauf jeweils mit den Zeigern enqueue und
dequeue, wie es Abbildung 2 zeigt.
Listing 10
LÖSUNG
Die fertige Implementierung
des Stacks.
public class Stack :
IStack {
internal Element top;
public TElement Pop() {
if (top == null) {
throw new
InvalidOperationException();
}
var result = top.Data;
top = top.Next;
return result;
}
public void Push(TElement element) {
var newTop = new Element {
Data = element,
Next = top
};
top = newTop;
}
}
Im Anschluss habe ich überlegt, wie die
Elemente untereinander sinnvoll zu verbinden
sind. Dabei gibt es mehrere Möglichkeiten:
❚ Jedes Element zeigt mit Next auf das ihm
folgende.
❚ Jedes Element zeigt mit Prev auf das
hinter ihm liegende.
❚ Jedes Element enthält sowohl Next- als
auch Prev-Zeiger.
Die doppelte Verkettung habe ich nicht
weiter berücksichtigt, da ich vermutete,
dass es auch ohne gehen muss. Dabei stand
nicht der Reflex im Vordergrund, dass eine
doppelteVerkettung mehr Speicher braucht
als eine einfache. Ich dachte eher daran,
dass ich bei doppelter Verkettung beim Einfügen
und Entfernen von Elementen zwei
Zeiger korrigieren muss. Das erschien mir in
jedem Fall mühsamer, als nur einen Zeiger
korrigieren zu müssen. Es siegte sozusagen
die pure Faulheit.
Es blieb noch die Frage zu klären, ob
Next- oder Prev-Zeiger sinnvoller sind. Das
habe ich mir wieder anhand meiner Skizze
überlegt. Wenn ein neues Element in die
Warteschlange eingefügt wird, muss enqueue
anschließend auf das neue Element
zeigen. Bei Verwendung von Next-Zeigern
muss dann nichts korrigiert werden, bei
Prev-Zeigern muss das bisher erste Element
auf das neue erste zurückverweisen.
Beides ist kein Problem, es ergibt sich also
hier noch keine Präferenz für eines der bei-
www.dotnetpro.de dotnetpro.dojos.2011 41
[Abb. 2]
enqueue-
und
dequeue-
Zeiger.