WinFuture-Forum.de: C# abhaenge Objecte verwalten - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Entwicklung
Seite 1 von 1

C# abhaenge Objecte verwalten


#1 Mitglied ist offline   nobido 

  • Gruppe: aktive Mitglieder
  • Beiträge: 217
  • Beigetreten: 20. April 07
  • Reputation: 9
  • Geschlecht:unbekannt

geschrieben 18. August 2021 - 19:34

*Edit
nabend die Gemeinde.
*Edit ende

Ich habe drei Objekte (Class_A, Class_B und Class_C).

Class_A stellt ein Object dar, welches (aktuelle) Zustaende misst; z.B. eine Zaehlwage, Temperatursensor, Gewichtswage etc.
Class_B stellt ein Object dar, welches Aktionen ausfuehren kann; z.B. Signalton bei erreichen einer Menge, einer Temperatur, eines Gewichts etc.
Class_C stellt ein Object dar, welches die Zustaende aus Class_A abruft und Class_B veranlasst Aktionen auszufuehren.


Nun will ich in EINEM Object vom Typ Class_C Objecte vom Typ Class_A und Class_B "verwalten".
Die auszufuehrende Aktion EINES Object vom Typ Class_B haengt ab vom Zustand (Messwert) eines oder mehrerer ((physikalisch)verschiedener) Objecte vom Typ Class_A.
Gleichzeitig koennen VERSCHIEDENE Objecte vom Typ Class_B zur Ausfuehrung von Aktionen veranlasst werden - in Abhaengigkeit vom Zustaend ein und desselben Object vom Typ Class_A.



Nun zum eingentlichen Anliegen:

Wie wuerdet IHR das organisieren? Per (mehrdiemensionalem) Array, Collection, Liste etc?
Ich dachte da nach laengerem ueberlegen an ein Struct, welches jeweils EINE Referenz auf ein Object vom Typ
Class_A und Class_B enthaelt. Und "Instanzen" von diesem Struct in einer Liste zu sammeln - List<StructType()>.

Objecte vom Typ Class_A laufen in einem (jeweils) eigenem Thread, bei Objecten vom Typ Class_B bin ich mir noch nicht sicher ob ich sie aktiv in einem eigenen Thread laufen lassen soll oder sie passiv belasse - sprich: sie agieren nur wenn noetig. Ist wohl auch eine Frage der Funktionalitaet von Class_B.

Die Abhaengkeiten der dann so verwalteten Objecte soll halt auch bearbeitet werden koennen.



...bissl steif formuliert, ich weiss.
Aber besser faellst mir grad net ein...

Tjoa... fuer Vorschlaege dankbar.

netten Abend.

n.

Dieser Beitrag wurde von nobido bearbeitet: 18. August 2021 - 19:36

0

Anzeige



#2 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 476
  • Beigetreten: 14. Juni 12
  • Reputation: 72
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 04. Oktober 2021 - 19:34

Hi,

ist zwar schon länger her und das Problem ist gewiss gelöst aber poste doch einfach beim nächsten mal deinen Code den du schon probiert hast.


Structs würde ich heute nicht mehr einsetzen - dafür gibt es Klassen :-).

Wenn du mit Threads arbeitest musst du auch dementsprechend mit Invokes bzw. Delegates arbeiten damit du aus dem aufrufenden Thread auch drauf zugreifen kannst.
Womit arbeitest du denn? WPF, WinForms oder Konsole?

Bei WPF ist generell MVVM das Mittel der Wahl und damit arbeitest du dann mit DependencyInjection, bei WinForms mit entsprechenden Delegates.

Ist immer wichtig zu wissen, mit was du arbeitest und mit welchem Framework :-).
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

#3 Mitglied ist offline   Tueftler 

  • Gruppe: Mitglieder
  • Beiträge: 5
  • Beigetreten: 11. Oktober 21
  • Reputation: 7

geschrieben 22. Oktober 2021 - 15:24

Ohne jetzt tiefere Ahnung von deinem Anwendungsfall zu haben,

würde ich die Objekte der Klasse A in eine Collection auf Klasse C legen.
Ich würde Klasse C aber nicht so bauen, dass sie die Sensoren fragt "Wie ist dein Wert?", denn dann braucht Klasse C irgendeine Schleife oder Timer, der durchgehend laufen muss, um regelmäßig zu fragen.
Meiner Meinung nach sollten solche Polling-Funktionen wenn möglich immer vermieden werden.

Da wäre es aus meiner Sicht charmanter, wenn die Sensor von Klasse A, Klasse C ihre Änderungen via Event mitteilen.
Du könntest dir also 100 Objekte deiner Klasse A initialisieren, dir die Events in Klasse C abbonieren und die 100 Objekte in eine Liste auf Klasse C packen.
Die Liste bräuchtest du dann hinterher nur noch um die Referenzen zu verwalten (Neue hinzufügen/aufräumen).
Objekte der Klasse C würden sich dann aber solange langweilen, bis die Sensoren eine Änderung mitteilen.

Wenn man den Sensoren dann vieleicht noch einen Wert mitgibt wie groß eine Änderung sein soll, damit sie für dich von Interesse ist, könnte man dafür sorgen dass Klasse C-Objekte noch weniger zu tun haben.


In den Eventhandlern könntest du dann die Änderungen auswerten und deine Klasse B-Objekte anweisen das Horn zu blasen. Die Actions könnten dann noch in Threads ausgelagert werden, damit bspw. ein Horn geblasen und zeitgleich eine Warnleuchte zum blinken gebracht werden kann, oder so.

Beim Typ der Collection kommts wieder so ein wenig darauf an, wie oft neue Objekte hinzugefügt/entfernt werden oder ob man eh nur fest 5 Stück braucht. Mit Listen kann man denke ich aber nie was verkehrt machen. Wobei du mit einem Dictionary bspw prüfen könntest, ob für etwas schon ein Sensorobjekt erstellt wurde. Ich denke da bspw. an eine Raumüberwachung, da möchte ich ja das Wohnzimmer nicht doppelt überwachen und könnte per Key "Sesor-<RaumNr/Name>" im Dictionary schnell prüfen, ob da schon Sensoren angemeldet sind oder nicht.
0

#4 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 476
  • Beigetreten: 14. Juni 12
  • Reputation: 72
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 22. Oktober 2021 - 16:33

Beitrag anzeigenZitat (Tueftler: 22. Oktober 2021 - 15:24)

würde ich die Objekte der Klasse A in eine Collection auf Klasse C legen.
Ich würde Klasse C aber nicht so bauen, dass sie die Sensoren fragt "Wie ist dein Wert?", denn dann braucht Klasse C irgendeine Schleife oder Timer, der durchgehend laufen muss, um regelmäßig zu fragen.
Meiner Meinung nach sollten solche Polling-Funktionen wenn möglich immer vermieden werden.
Da wäre es aus meiner Sicht charmanter, wenn die Sensor von Klasse A, Klasse C ihre Änderungen via Event mitteilen.


Nöööö - das macht man mittels Interface ==> INotifyPropertyChanged oder INotifyCollectionChanged - dann benötigt man die Events nicht.

Zitat

Du könntest dir also 100 Objekte deiner Klasse A initialisieren, dir die Events in Klasse C abbonieren und die 100 Objekte in eine Liste auf Klasse C packen.
Die Liste bräuchtest du dann hinterher nur noch um die Referenzen zu verwalten (Neue hinzufügen/aufräumen).
Objekte der Klasse C würden sich dann aber solange langweilen, bis die Sensoren eine Änderung mitteilen.


Entweder man würde sowas über Tasks laufen lassen weil die im Hintergrund laufen oder über Backgroundworker....

Zitat

In den Eventhandlern könntest du dann die Änderungen auswerten und deine Klasse B-Objekte anweisen das Horn zu blasen. Die Actions könnten dann noch in Threads ausgelagert werden, damit bspw. ein Horn geblasen und zeitgleich eine Warnleuchte zum blinken gebracht werden kann, oder so.


Wie schon erwähnt ==> eher mit Tasks arbeiten anstatt mit Threads.

Zitat

Beim Typ der Collection kommts wieder so ein wenig darauf an, wie oft neue Objekte hinzugefügt/entfernt werden oder ob man eh nur fest 5 Stück braucht. Mit Listen kann man denke ich aber nie was verkehrt machen. Wobei du mit einem Dictionary bspw prüfen könntest, ob für etwas schon ein Sensorobjekt erstellt wurde. Ich denke da bspw. an eine Raumüberwachung, da möchte ich ja das Wohnzimmer nicht doppelt überwachen und könnte per Key "Sesor-<RaumNr/Name>" im Dictionary schnell prüfen, ob da schon Sensoren angemeldet sind oder nicht.


Für Überwachungen gibt es ObservableCollections - die sind dafür ausgelegt und gedacht. List<T> eher nicht. Dictionaries sind zwar nett, aber auch bei ObservableCollections kannst du dir entsprechende Restriktionen bauen ==> z.B. über den entsprechend zugewiesenen Klassentyp....
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
1

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0