Queue Action Engine

Hallo Roumaen

Ja, Roumaen, schwieriger Fall. Ich glaube, so wird das auf Dauer nix. Ich befürchte, hier werden die Nachteile die Vorteile überwiegen. Für mich sieht das VI aus, als ob es einen Selbstzweck habe: nämlich das Verwalten von Queues. Das mag theoretisch gut sein. Auch für das "Verwalten von Queues" kann man eine "Klasse" machen - aber: Eigentlich willst du doch bestimmt keine Queues verwalten, sondern den Inhalt der Queues, z.B. Daten. Oder du willst Queues als Schnittstelle zwischen Modulen verwenden. Queues/Melder sollen ja Mittel zum Zweck sein, nicht Selbstzweck.

Ich mach das immer so:
Ich habe ein VI, Enumerator gesteuert, das Queues/Melder erzeugt, schließt und die Referenzen der Queues/Melder ausgibt. Erzeugen und Schließen wird genau einmal aufgerufen - am Anfang und am Ende des Programmes (das entspricht dem ersten und dritten Case in deinem VI). Während des normalen Ablaufes wird es auch immer aufgerufen, aber nur um die Referenzen zwecks Schreiben/Lesen von Queue/Melder zu holen. Das tatsächliche Schreiben/Lesen, was in deinem VI der mittlere Case ist, wird im entsprechendem Algorithmus gemacht.

Was deine Methode und meine gemeinsam haben, ist, dass keine expliziten Drahtleitungen (nur kurze Drähte zwischen zwei neben einander liegenden Symbolen) notwendig sind.

Skalierbar und wiederverwendbar ist meine Methode deswegen, weil man nur den Typ der Queues änder muss, das Verfahren und die Vorlagen an sich aber beibehalten werden können. Dass eine Anpassung des Typs Folgeanpassungen zur Folge haben kann, nehme ich in Kauf.