DI-konformes Vorgehen

[steinadler]

Hallo,

 

bei einem Projekt benötige ich zwei Geräte, einen Sensor und eine Steuerung. Ebenso habe ich eine Klasse 'Control' die beide Geräte miteinander kommunizieren lässt. Diese bekommt dann von Sensor und Steuerung jeweils eine Instanz.

Allerdings bekomme ich erst nach dem Verbinden zum Sensor eine entsprechende Instanz zurück (je nach Firmware-Version).

Wenn ich mich nun während der Programmlaufzeit vom Sensor trenne und neu verbinde, könnte es sein, dass sich die Instanz des Sensors ändert.

 

Wie übergebe ich denn meiner 'Control'-Klasse am besten die beiden Instanzen? Lässt sich das per DependencyInjection überhaupt umsetzen (aktuell nutze ich Ninject)?

Oder erzeuge ich besser eine übergeordnete Klasse 'Device' welche meine beiden Geräteinstanzen enthält und übergebe diese der 'Control'-Klasse?

 

Danke schonmal

 

[Whiz-zarD]

Du hast also drei Klassen:

Sensor
Steuerung
Controller

Von Sensor und Steuerung erzeugst du jeweils eine Instanz und übergibst sie an Controller. Vom pysikalischen Sensor selber erhälst du ja keine Instanz. Höchstens nur eine Nachricht, wenn er aktiv ist. Wenn du darauf dann reagieren möchtest, dann muss in der Sensor-Klasse auf diese Nachricht reagiert werden und ein Event auslösen, an der sich der Controller ranhängen kann.

Oder ist verstehe dein Problem nicht.

Bearbeitet 5. Mai 2021 von Whiz-zarD

[steinadler]

vor 16 Minuten schrieb Whiz-zarD:

Du hast also drei Klassen:

Sensor
Steuerung
Controller

Von Sensor und Steuerung erzeugst du jeweils eine Instanz und übergibst sie an Controller. Vom pysikalischen Sensor selber erhälst du ja keine Instanz. Höchstens nur eine Nachricht, wenn er aktiv ist. Wenn du darauf dann reagieren möchtest, dann muss in der Sensor-Klasse auf diese Nachricht reagiert werden und ein Event auslösen, an der sich der Controller ranhängen kann.

Oder ist verstehe dein Problem nicht.

 

Genau, diese dre Klassen.

Ich habe noch jeweils eine Klasse SensorBuilder. Diese besitzen eine Connect-Methode und ein Event, welches ausgelöst wird, sobald eine entsprechende Instanz erzeugt wurde. Dieses Erzeugen passiert, nachdem während Connect() die Seriennummer und Version des Gerätes geprüft wurden. Das ganze läuft asynchron, bis eben das Event ausgelöst wird.

 

Die Frage ist nun, wie ich die Instanz an meine Controller-Klasse weitergebe.

 

Ich möchte ja gern DI nutzen. Aber ich habe bisher keine Möglichkeit gefunden, dass ich die Instanz des Sensors (z.B. beim neu verbinden) in meiner Controller-Klasse verändern kann.

[pr0gg3r]

Die erste Frage die man sich stellen sollte wäre erst mal der Lebenszyklus der Klassen. Sind denn "Sensor" und "Steuerung" nur einmal vorhanden (Singelton)? Oder können mehrere vorhanden sein?

Dependency-Injection macht eigentlich immer erst dann Sinn, wenn man eine Art Service oder Provider hat, der an verschiedenen Stellen genutzt werden soll. Hier sehe ich das aber noch nicht so ganz, denn "ein Controller hat jeweils ein Sensor und eine Steuerung" (falls ich den Usecase erst mal richtig verstanden habe). Wo es z. B. Sinn machen würde: du hast einen ControllerService (der wiederum eine Steuerung und einen Sensor hat) und dieser kann dann an verschiedenen Stellen per DI eingebunden haben (z. B. dass von verschiedenen Fenstern aus drauf zugegriffen werden kann).

Auch finde ich das Wording nicht ganz passend. "Steuerung" und "Controller" sind sich zu ähnliche Begriffe, denn wenn man Controller übersetzt kommt da irgendwas in Richtung Steuerung raus.

vor 1 Stunde schrieb steinadler:

Allerdings bekomme ich erst nach dem Verbinden zum Sensor eine entsprechende Instanz zurück (je nach Firmware-Version).

Wieso existiert eine Instanz erst, wenn eine Verbindung beseht? Kann man nicht irgendetwas in Richtung State bauen? Dass der State z. B. von "connecting" auf "connected" springt oder in die Richtung und evtl. noch ein Event auslöst. Asynchron sind auch immer Observables ein gutes Stichwort nach dem Motto "subscribe dich mit service.connect(...) (was das Observable zurück gibt) und wenn die Verbindung steht, dann mach doch dies und das". Aber kann auch sein dass ich zu weit weg denke, bin in so Hardware-Ansteuerungs-Themen nicht so drin.

[steinadler]

Die Begriffe Controller und Steuerung sind etwas unglücklich gewählt, das stimmt. Controller ist ein Mikrocontroller und Steuerung ist eigentlich eine StateMachine/Schrittkette.

Prinzipiell habe ich eine StateMachine, welche einen Ablauf beinhaltet (etwas wird vom Sensor eingelesen und der Controller verarbeitet es; anschließend gibt ein Drucker ein Etikett aus, z.B.). Diese Schrittkette gibt es im Programm nur einmal.

 

Bisher habe ich dieser Schrittkette per Konstruktor jeweils die Instanzen von Sensor, Controller und Drucker übergeben.

Problem: Macht man ein Firmware-Update des Sensors und verbindet den Sensor neu, dann wird eine neue Instanz des Sensors erzeugt, da für die neue Firmware eine spezielle Implementation benötigt wird. Durch die Constructor-Injection musste bisher immer nach Firmware-Update das Programm neu gestartet werden - das wollte ich gern vermeiden.

Wie sage ich jetzt der Schrittkette, dass sich die Sensorinstanz geändert hat? Ich wollte die Schrittkette eigentlich nicht neu erstellen sondern nur die Sensorinstanz austauschen.

 

Wenn DependencyInjection dafür völlig ungeeignet ist, dann mach ich es auf konventionellem Weg mit Events und einer Setter-Methode, die die Geräteinstanz austauscht.

 

[Whiz-zarD]

vor 4 Minuten schrieb steinadler:

Problem: Macht man ein Firmware-Update des Sensors und verbindet den Sensor neu, dann wird eine neue Instanz des Sensors erzeugt, da für die neue Firmware eine spezielle Implementation benötigt wird.

Wenn sich aber die Implementierung des Sensors ändert, wie willst du denn die Implementierung im laufenden Betrieb ändern? Ein Neustart muss doch zwangsläufig erfolgen. Du kannst doch mitten im Betrieb nicht die Assembly austauschen.

[steinadler]

vor 6 Minuten schrieb Whiz-zarD:

Wenn sich aber die Implementierung des Sensors ändert, wie willst du denn die Implementierung im laufenden Betrieb ändern? Ein Neustart muss doch zwangsläufig erfolgen. Du kannst doch mitten im Betrieb nicht die Assembly austauschen.

Es handelt sich dabei um eine Assembly, welche sämtliche Firmwareversionen des Sensors abdeckt.

Man hat ein SensorBuilder-Klasse mit der man Connect() aufruft und irgendwann per Event ein Interface auf den Sensor zurückbekommt. Die Assembly ändert sich praktisch nicht, nur die Firmwareversion des Controllers.

[Whiz-zarD]

 

vor 59 Minuten schrieb steinadler:

Es handelt sich dabei um eine Assembly, welche sämtliche Firmwareversionen des Sensors abdeckt.

Du schreibst aber, wenn es eine neue Firmware gibt, muss dein Tool darauf reagieren können. Folglich muss doch auch das Tool angepasst werden und somit auch die Assembly. Deine "spezielle Implementierung" kommt ja nicht dahergeflogen. Ich verstehe dich irgendwie nicht.

[steinadler]

vor 14 Stunden schrieb Whiz-zarD:

 

Du schreibst aber, wenn es eine neue Firmware gibt, muss dein Tool darauf reagieren können. Folglich muss doch auch das Tool angepasst werden und somit auch die Assembly. Deine "spezielle Implementierung" kommt ja nicht dahergeflogen. Ich verstehe dich irgendwie nicht.

Es ist eher so, dass der Kunde einen Sensor kauft und die PC-Software permanent aktuell hält. Daraus ergibt sich: (alter) Sensor neue Software. Inzwischen gibt es jedoch eine neue Sensor-Firmware, welche von der bereits aktuellen PC-Software schon unterstützt wird.

Man musste bisher immer Firmware aktualisieren und dann die Software neu starten. Diesen Neustart möchte ich gern verhindern.

 

Oder: Kunde trennt die Verbindung zum Sensor und tauscht den Sensor zu einem neueren Modell, welches auch von der Software unterstützt wird.

Ich müsste also meine Geräteinstanzen während der Programmlaufzeit irgendwie austauschen können.

Wie gesagt, vielleicht ist DI dafür aber auch nicht gemacht.

[Whiz-zarD]

vor 14 Minuten schrieb steinadler:

Wie gesagt, vielleicht ist DI dafür aber auch nicht gemacht.

Richtig. Dafür ist DI nicht gedacht. Wie der Name schon sagt, wird bei DI bei der Erstellung einer Instanz seine Abhängigkeiten injiziert. Dabei wird dann zwischen zwigende und optionale Abhängigkeiten unterschieden. zwigende Abhängigkeiten werden dann meist über die Konstruktor injiziert.

Wenn es aber schon einen Mechanismus gibt, der den Sensor erkennt und daraufhin auch eine neue Instanz erstellt, könnte man da auch ein Event ansteuern, an der sich die Steuerung ranhängt und über das Event könnte die Instanz getauscht werden.

[steinadler]

vor 21 Minuten schrieb Whiz-zarD:

Richtig. Dafür ist DI nicht gedacht. Wie der Name schon sagt, wird bei DI bei der Erstellung einer Instanz seine Abhängigkeiten injiziert. Dabei wird dann zwischen zwigende und optionale Abhängigkeiten unterschieden. zwigende Abhängigkeiten werden dann meist über die Konstruktor injiziert.

Wenn es aber schon einen Mechanismus gibt, der den Sensor erkennt und daraufhin auch eine neue Instanz erstellt, könnte man da auch ein Event ansteuern, an der sich die Steuerung ranhängt und über das Event könnte die Instanz getauscht werden.

Ah okay,

 

das heißt, das Paradebeispiel von Ninject

public class WarriorModule : NinjectModule
{
    public override void Load() 
    {
        Bind<IWeapon>().To<Sword>();
        Bind<Samurai>().ToSelf().InSingletonScope();
    }
}

ergibt auch nur Sinn, solange man beim Programmstart festlegt, ob man "Sword" auswählt.

Wenn man nun das Werkzeug während der Programmlaufzeit wechseln möchte, also als "Sword" etwas anderes machen?

 

Das würde doch dann auch nicht mehr mit DI funktionieren oder?

 

Ich habe bisher immer konventionell ohne DI programmiert, mit Ereignissen usw.

 

[Whiz-zarD]

Du schreibst doch selber:

vor 17 Stunden schrieb steinadler:

Ich habe noch jeweils eine Klasse SensorBuilder. Diese besitzen eine Connect-Methode und ein Event, welches ausgelöst wird, sobald eine entsprechende Instanz erzeugt wurde. Dieses Erzeugen passiert, nachdem während Connect() die Seriennummer und Version des Gerätes geprüft wurden. Das ganze läuft asynchron, bis eben das Event ausgelöst wird.

Also gibt es jemanden, der die Instanz für den Sensor erstellen kann und es wird sogar ein Event ausgelöst. Dann muss dieser SensorBuilder als Abhängigkeit in deine Steuerung übergeben werden und nicht der Sensor. Die Steuerung kann dann auf das Event reagieren und den Sensor holen.

Eine andere Möglichkeit die mir einfällt, die ich jetzt wohl eher präferieren würde ist, dem SensorBuilder die Steuerung als Abhängkeit zu geben und wenn sich die Instanz ändern soll, dann kann der SensorBuilder dies übernehmen

Aber was nun genau die bessere Variante ist, kann ich nicht sagen, da ich den Code nicht kenne.