In diesem Blogbeitrag geht es um ein spezielles „Composite Pattern“ (zusammengesetztes Muster). Es ermöglicht uns, mit einer Hierarchie von Objekten (wie einer n-Baumstruktur) auf einheitliche Weise zu arbeiten. Durch die Entwicklung eines Tree-Nodes, der Betriebsmodi ausführen und eine beliebige Anzahl von Child-Nodes verwalten kann, können wir alle Baumelemente in einem Aufruf durchlaufen.
Die Maschinen, die wir programmieren, haben alle eine hierarchische Struktur (siehe Abbildung 1).
Ein leidiges Thema bei den Maschinen sind die Betriebsmodi, daher sollen diese nun als Beispiel dienen. Das Beispiel ist sehr vereinfacht und unvollständig, da es nur dazu dient, ein Prinzip zu erklären Ein vollständiges Beispiel würde den Rahmen des Blogbeitrags sprengen.
Die Maschine hat drei Stationen: eine Zuführ-, eine Ausgabe- und eine Pressstation.
Da ein Bild mehr sagt als tausend Worte, schaue dir Abbildung 2 an. Ich habe nur die Struktur des Inlets gezeichnet, um die Baumstruktur zu verdeutlichen. Die anderen Stationen wurden weggelassen.
Wir erstellen einen Tree-Node, der einen Betriebsmodus ausführen kann und beliebig viele Kinder haben kann. Außerdem sollte der Node den entsprechenden Betriebsmodus für alle Child-Nodes aufrufen, sodass wir einen Traversierungsaufruf über alle Baumelemente erhalten. Die Aufrufe des entsprechenden Betriebsmodus sollten über eine Schnittstelle erfolgen, die ein Client aufrufen kann (Operation Mode Handling und Parent-Node).
Beim Aufruf des Constructor (FB_init) sollte der Parent-Node übergeben werden, der Child-Node ruft die Methode addChildNode mit sich selbst auf. Auf diese Weise sparen wir uns die Methoden zum Anhängen und die Deklarationsstruktur spiegelt auch die Baumstruktur wider (einfache Handhabung und gute Lesbarkeit). Die Klassenstruktur ist in Abbildung 3 dargestellt und die Grundidee der Kommunikation ist in Abbildung 4 dargestellt.
In der Einleitung habe ich davon gesprochen, dass es sich hierbei um eine spezialisierte Form des Composite Pattern handelt. Das klassische Composite Pattern unterscheidet zwischen Node und Leaf, d. h. wie bei einer Ordnerstruktur gibt es den Ordner (Root Node), der Dateien (Leaves) und Unterordner (Nodes) enthält. Ein Ordner kann nicht gleichzeitig eine Datei sein. In unserem Beispiel kann jedoch jeder Node ein Leaf sein und auch Nodes und Leaves enthalten.
Für die Umsetzung des Beispiels werden unsere Cinnamon-Framework-Bibliotheken benötigt. Sie finden sie in unserem Style Guide.
Im Beispiel werden CNM_AbstractObject, CNM_RetrunTypes, CNM_Collections, CNM_State-Machine-Lib, CNM_CollectionInterfaces und CNM_CycleManagerInterface verwendet.
Wie immer beginnen wir mit den Schnittstellen. Wir benötigen die drei Schnittstellen INodeApi, INode und INodeBehavior. Die Struktur der Schnittstellen ist in Abbildung 5 dargestellt.
INodeApi
INode
INodeBehavior
Zuerst implementieren wir die drei Delegates für Automatic, Homing und Manual, da diese für unseren AbstractNode benötigt werden. Die Struktur der Delegates ist in Abbildung 6 zu sehen.
AutomaticBehavior
HomingBehavior
ManualBehavior
Jetzt kann endlich der Abstract Node implementiert werden und damit der Kern unseres Konzepts. Es gibt dabei drei Methoden, die man verstehen sollte:
Der Constructor (FB_init), da hier unsere Baumstruktur aufgebaut wird.
Die geschützte Methode handleMode, da sie die Ausführung und Rückgabewerte des eigenen Node und der Child-Nodes verwaltet.
Die Property stopRequest, da sie eine Stoppanforderung mit allen Child-Nodes teilt.
Wenn ich nun eine Klasse für die Maschine, eine Station, eine Funktionsgruppe oder ein Gerät erstellen möchte, muss diese Klasse nur von AbstractNode erben. Dann kann ich die Klasse einfach zu unserer Hierarchie hinzufügen. Für die Funktionalität des Node werden die Methoden runAutomatic, runHoming, runManual bei Bedarf überschrieben. Abbildung 7 fasst die Struktur von AbstractNode noch einmal zusammen.
Jetzt brauchen wir einen Client, der dem Baum sagt, was er tun soll. Das ist unser Operation Mode Handler. In unserem Beispiel nehmen wir an, dass der Opmode eine vorzeichenlose kurze Integerzahl ist, die auf magische Weise von der HMI kommt. Wie bereits gesagt, ist das Beispiel unvollständig. Der Operation Mode Handler sollte einen Node erhalten und den Node dazu bringen, das zu tun, was getan werden muss.
Aus Gründen der Lesbarkeit erstellen wir eine Enumeration, die die verschiedenen Betriebsmodi darstellt.
OpMode enumeration
Class OperationMode
Abbildung 8 gibt dir einen Überblick über unseren Client.
Keine Sorge, ich werde hier keine Maschine implementieren, ich zeige dir nur, wie es aussehen könnte.
Infeed
Machine
Main
Das Beispiel zeigt sehr gut, wie einfach es ist, hierarchische Kompositionen zu erstellen und zu verwenden, wenn sie dieselben Methoden/Vorgänge bereitstellen. Die Aufrufe dauern nicht länger, als wenn du jeden Aufruf in den Hauptteil einfügst, aber es liest sich gut, weil es die Struktur unserer Maschine widerspiegelt.
