OOP in TwinCat nach IEC 61131-3: Workaround für Overloading?

[LeFish]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo allerseits,

ich habe ein Objekt A (bildet einen Sensor A ab) und ein Objekt B (bildet einen Sensor B ab).

Objekt B erbt von Objekt A.

Sensor B ist immer auch ein Sensor A (mit erweiterten Funktionen).
Aber Sensor A ist kein Sensor B (hat ja die speziellen Funktionen nicht).

Eigentlich ein klassischer Fall von Vererbung, wenn denn Methoden überladen werden könnten.

Ich habe eine Init-Methode für Objekt A, die 2 Parameter benötigt (E1, E2) und die Sensoreigenschaften festlegt.
Die Init Methode für Objekt B soll jene von Objekt A überschreiben und benötigt 2 zusätzliche Parameter (E1, E2, E3, E4), der Sensor kann ja mehr.

Folgende Möglichkeiten habe ich probiert:

* Beide Methoden heißen Init. Dann benötigt aber die Init-Methode von Objekt A auch die Parameter E3, E4, die dann ins Leere gehen, da der Sensor das ja nicht kann.
* 2 getrennte Methoden Init_A und Init_B.

Beide Möglichkeiten finde ich nicht gut von der Handhabung her.

Gibt es noch eine Möglichkeit, um das sauber zu lösen?

Danke!

Beste Grüße
LeFish

 

[StructuredTrash]

Ich habe es in einer vergleichbaren Situation so gelöst (ich verwende mal Deine Namen Objekt A und Objekt B zum besseren Verständnis):
1) Das Objekt A als abstrakte Basisklasse angelegt. Es enthält die komplette Funktionalität und eine private oder protected Methode prvInit.
2) Von der Basisklasse dann zwei FBs für Objekt A und Objekt B abgeleitet, die jeweils eine eigene public Methode pubInit haben.
Beide Init-Methoden rufen zunächst die prvInit der Basisklasse auf. Die Init-Methode von Objekt B führt dann noch zusätzliche Initialisierungen aus.

Für zwei FBs sicher vertretbar, wenn man die Vererbungshierarchie noch fortführen möchte, wird es aber sperrig. Dann müsste man ja für jeden FB, von dem man noch mal ableiten will, eine eigene abstrakte Basisklasse schreiben.

 

[LeFish]

Zuviel Werbung?
-> Hier kostenlos registrieren

1) Das Objekt A als abstrakte Basisklasse angelegt. Es enthält die komplette Funktionalität und eine private oder protected Methode prvInit.

Wäre es zum Beispiel auch denkbar der Basisklasse gar keine Initialisierungsmethode zu geben und diese erst in den instanzierbaren Klassen anzulegen? Sehrwohl würde ich der Basisklasse aber eine Eigenschaft "x_isInit" oder so geben, um anzuzeigen, dass eine Initialisierungsmethode zu erstellen ist.

Für zwei FBs sicher vertretbar, wenn man die Vererbungshierarchie noch fortführen möchte, wird es aber sperrig. Dann müsste man ja für jeden FB, von dem man noch mal ableiten will, eine eigene abstrakte Basisklasse schreiben.

Auch hier würde sich meiner Meinung nach anbieten jene Methoden, welche in den instanzierbaren Klassen unterschiedlich sind auch erst dort anzulegen. Alle Methoden, die für eine jeweilige Hierarchieebene gleich sind werden in der Abstract-Klasse angelegt.

Interessant wird es bei tiefen Hierarchien und verteilter Programmierung. Hier muss ja demjenigen der die letzte, instanzierbare Klasse schreibt mitteilen, wie er die Init-methode schreiben muss.
Ich kenn mich noch nicht so mit TwinCAT aus, aber würden da nicht evtl. Pragmas helfen, durch die der Programmierer diejenigen Vorgänge die in dem gültigen Strang der Klassenhierarchie die Initialisierungsvorgänge filtern kann? Siehe: https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2526889867.html&id=

Wäre es eine Möglichkeit ein Benutzerdefiniertes Pragma {to_be_initialized} anzulegen und das dann iwie in der IDE (zB mittels IntelliSense) anzeigen zu lassen, wenn man sich in einer abgeleiteten Klasse befindet?

Beste Grüße
LeFish

 

[StructuredTrash]

Wäre es zum Beispiel auch denkbar der Basisklasse gar keine Initialisierungsmethode zu geben und diese erst in den instanzierbaren Klassen anzulegen?

Denkbar ist das schon, aber dann musst Du den Init-Code für Objekt A in beiden Init-Methoden schreiben. Und das soll mit der OOP ja gerade vermieden werden.

Interessant wird es bei tiefen Hierarchien und verteilter Programmierung. Hier muss ja demjenigen der die letzte, instanzierbare Klasse schreibt mitteilen, wie er die Init-methode schreiben muss.

Gerade deshalb würde ich auf die private/protected Methoden in den Basisklassen nicht verzichten. Wenn jemand einen weiteren FB ableiten will, braucht er nur diese Methode der Basisklasse aufrufen und kann sich dann auf die zusätzliche Funktionalität des abgeleiteten FBs konzentrieren.