Designfrage: Vererbungshierarchie von ComPort-Klassen mit verschiedenen Befehlssätzen

Guten Tag Community,
ich entwickle eine Applikation in der ich zwei DLLs benutze.
ich steuere über COMPort Karten, die unterschiedliche Befehle haben.#

Alle unterschiedlichen Karten haben einen Satz befehle, die gleich sind. und einen Satz befehle, die sich unterscheiden.

deshalb habe ich die Klassen mit vererbung aufgebaut.

Die basisklasse, die die Kommunikation mit den Karten betreibt habe ich von IO.Serialport erben lassen.

	public class clsFrameLayer : SerialPort

Desweiteren erbt die Klasse, die die Basisbefehle für die Karte zustänig ist von der oben genannten.

	public class clsAdvancedSerialBus : clsFrameLayer

und nun kommen die Klassen für die einzelnen Karten ins Spiel, die die speziellen Befehle für diese Karten ausführen

	public class clsRelaisKarte : clsAdvancedSerialBus

Bis hierhin alles gut und recht

in der Anwendung benutze ich die Klasse clsRelaisKarte mit

	UserPort1 = new clsRelaisKarte();

Aber ich brauche hier etwas differenziertes. Irgendwas wie

	Object UserPort1 = 

Was kann ich machen um das ganze nicht in eine Klasse zu packen, die dann die ganzen funktionen an die Anwendung weiterleitet wie ich es jetzt andenke,

Ausserdem hat die BasisKlasse von allem noch Events, die ich in der Anwendung brauche.

Hat bitte jemand eine IDEE

Hallo Knackes,

wofür braucht man den soviele Vererbungen?
Geht das nicht auch mit einer?

mfg.
markus111

Hallo Knackes,

irgendwie habe ich deine Frage nicht verstanden. Was meinst du mit "was differenziertes"?

herbivore

Es würde mit einer Vererbung gehen, wenn ich die Funktionen der AdvancedSerialBus in den Framelayer einbauen würde

Die Frage ist wie kann ich es machen, dass je nach angeschlossener karte die Klasse angesprochen wird, die für die entsprechende Karte die richtigen Befehle reit hält?

Hallo Knackes,

dafür gibt es passende Entwurfsmuster. Hier vermutlich abstrakte Fabrik oder Fabrikmethode.

herbivore

Wenn du das ganze via Vererbung und Polymorphie machen möchtest, ist es vllt. sinnig die einzelnen Implementierungen mit internal oder protected vor der Außenwelt zu verstecken und den Zugriff nur über Factory und einer öffentlichen Schnitstelle/abstrakte Basis-Klasse bereitszustellen. Ähnlich wie beispielsweise die XmlReader und XmlWriter-Klassen.

Bei zu vielen Implementationen und schlechter Doku (oder auch zuviel Doku), ist es für den EndUser der Klassen schwierig die richtige abgeleitete Klasse zu finden.