003
23.06.2003, 10:32 Uhr
ao
(Operator)
|
Zitat: |
Re-Animator postete Hallo,
hab da eine Frage bezüglich des Testfiles einer Array Implementierten Warteschlange, wie könnte so ein queuetest.c File aussehen ? queue.c , queue.h sowie makefile konnten bereits erstellt werden jedoch weiß ich nicht genau in welchen Umfang queuetest die queue.h braucht? Einfach einbinden? Kann mir jemand noch etwas zur Abstraktion von Implementierungsdetails in C sagen? Was kann ich mir darunter genau vorstellen? Warum wird dies überhaupt gebraucht (Zweck/Sinn?)
Vielen Dank
|
Also, normalerweise enthält queue.h die Schnittstelle der Queue, d.h. alles, was ein Programmierer über die Queue wissen muß, um sie benutzen zu können. Das dürften etwa 4 Funktionen sein:
QueueCreate () - Erzeugen und Initialisieren einer Queue QueuePut () - An einem Ende einen Datenblock in die Queue stecken QueueGet () - Am anderen Ende einen Datenblock wieder rausholen QueueDestroy () - Die Queue und alle noch enthaltenen Datenblöcke zerstören.
Wenn die Queue eine Längenbegrenzung hat, könnten auch noch QueueGetMaxLength () - maximale Anzahl speicherbarer Datenblöcke abfragen und QueueGetLength () - aktuelle Anzahl gespeicherter Datenblöcke abfragen sinnvoll sein.
Vielleicht hab ich noch was vergessen, aber diese 4 bzw. 6 Prototypen gehören ins queue.h-File und sonst nichts.
Alles andere ist "Implementierungsdetail". Zum Beispiel mußt du dir die Positionen merken, auf denen die nächsten Put- und Get-Aktionen ausgeführt werden. Oder wie QueuePut und QueueGet Datenblöcke in die Queue stecken bzw. herausholen. Oder wie QueueGetLength die Anzahl der gespeicherten Datenblöcke errechnet.
Dazu ist es vermutlich ratsam, einige interne Hilfsfunktionen zu haben, mit denen du die Aufgaben, die Put und Get und die anderen ausführen, sinnvoll gliedern kannst. Aber diese Hilfsfunktionen tauchen nicht im queue.h-File auf und sie werden am besten auch "static" deklariert; damit wird verhindert, daß sie von außerhalb des queue.c-Moduls aufgerufen werden können.
Das hängt natürlich alles zusammen und ist stark davon abhängig, wie die Queue realisiert ist (es wäre z.B. denkbar, das nicht als Array zu machen, sondern als verkettete Liste, mit anderen Vor- und Nachteilen), aber das sind alles Dinge, von denen der Benutzer (der, der QueueGet und QueuePut aufruft) nichts wissen will. Der erwartet einfach, daß die Queue funktioniert und sich um ihren internen Kram selber kümmert.
D.h. die Implementierungsdetails werden gekapselt und abstrahiert: Der Benutzer bekommt nur das zu sehen, was er sehen soll: Die einfachen Interface-Funktionen. Daß das Ganze intern viel komplizierter ist, will er nicht wissen, und es geht ihn auch nichts an.
Denn: Nur dadurch kannst du die Implementierung ändern, wenn das nötig ist. Du kannst die Queue heute so programmieren und morgen ganz anders, z.B. mit einer verketteten Liste. Wenn die Schnittstellenfunktionen erhalten bleiben, merkt kein Mensch was davon, daß die Implementierung sich geändert hat. Das geht natürlich nur, wenn du die Interna verbirgst.
Klarer?
ao |