C# Clean Code - Events registrieren

[Ghost_Rider_R]

Hallo zusammen,

da ich mich viel mit Clean Code beschäftige und über ein Problem gestolpert bin, wo ich mir selbst nicht so ganz sicher bin, was da denn nun der bessere Ansatz ist, frage ich einfach mal euch 😊.

Zum einen gibt es ja bei Events die Publisher, bei denen man beliebig viele EventHandler registrieren kann. Sollten diese Publisher nun immer via Interface von außen zugänglich sein oder könnte es auch Sinn machen, dass man der Klasse Objekte z.B. im Konstruktor übergeben muss, und die Klasse registriert die anderen Klassen dann direkt bei sich selbst innerhalb des Konstruktors?

Ebenso das Gegenbeispiel. Ich habe eine Klasse, bei der ich meinen EventHandler registrieren muss, damit dieser bei einem auftretenden Event ausgeführt wird. Sollte dieses Registrieren beim Publisher nach der Erstellung der Objekte passieren, also außerhalb der Klassen z.B. in der Main-Methode oder sollte man diese Klasse einem anderen Objekt übergeben und der übernimmt die Registrierung für einen z.B. innerhalb des Konstruktors?

Beide Beispiele zielen also letztlich auf die selbe Frage ab, nur aus verschiedenen Blickrichtungen. Ich freue mich schon auf eure Meinungen und Lösungsvorschläge.

Noch ein Hinweis, ja man sollte natürlich überall Schnittstellen einziehen, aber das soll jetzt gar nicht Teil der Diskussion sein 😊,
es geht also nur um den Ort der Registrierung.

LG Ghost.

 

[Ack der III]

Ein Konstruktor hat die Aufgabe, aus einem Stück Speicher ein valides Objekt zu erstellen.
Entsprechend sollte die Registrierung der EventHandler in eine Methode registerEventHandler() ausgelagert und diese dann separat aufgerufen werden.
Alleine schon, wenn du für einen EventHandler einen UnitTest schreiben möchtest, möchtest du nicht, dass sich dieser irgendwo automatisch registrieren will.

 

[Ghost_Rider_R]

Gibt es noch weitere Meinungen? Und verstehe ich deine Antwort richtig, das Abonnieren soll nicht in den Konstruktor? @Ack der III

 

[KitKat::new()]

Ich denke das muss man situationsbedingt entscheiden.
Will man eine einache abgeschlossene Einheit/API nach außen haben, dann würde ein Registrieren im Konstruktor Sinn ergeben, insbesondere wenn die Klasse ohne die Registrierung nicht ordnungsgemäß funktioniert.

Will man dagegen möglichst flexibel bleiben und es gibt keine explizite API für die Klasse nach außen, bietet es sich an die Registrierung außerhalb zu machen.

Alleine schon, wenn du für einen EventHandler einen UnitTest schreiben möchtest, möchtest du nicht, dass sich dieser irgendwo automatisch registrieren will.

Es ist ja nicht irgendwo, sondern bei der dem Konstruktor übergebenen Instanz.

 

[Ack der III]

Ziel von Clean Code ist es, den sogenannten "Mental Load" beim Lesen von Programmcode auf ein Minimum zu reduzieren. Das bedeutet, dass beim Lesen von Code sofort erkennbar sein soll, was dieser Code macht, insbesondere ohne in die Implementierung einer Methode reinschauen zu müssen. Dies erleichtert zu verstehen, was Programmcode macht und verhindert Überraschungen, beim Ändern, Erweitern oder schlicht Aufrufen dieses Programmcodes, die für gewöhnlich in Programmfehlern resultieren. Für den vorliegenden Fall sind hier zwei Regeln des Clean Codes von besonderer Relevanz:

1. Eine Methode soll nur eine einzige Aufgabe/Funktion haben.
2. Eine Methode soll einen Namen haben, an dem man die Aufgabe/Funktion der Methode sofort erkennt.

Eine separat aufzurufende Methode registerEventHandler() erfüllt beide Regeln. Einen Konstruktor kann man als besondere Art von Methode betrachten, mit der Spezialaufgabe aus einem Stück Speicher ein valides Objekt zu erstellen. Würde der Konstruktor darüber hinaus noch weitere Dinge machen, dann würde Regel 1 verletzt werden. Da darüber hinaus Programmiersprachen es für gewöhnlich nicht erlauben, Konstruktoren beliebige Namen zu geben, würde gleichzeitig auch Regel 2 verletzt werden, da durch den Namen des Konstruktors nicht erkannt werden kann, das dieser neben der Konstruktion noch etwas anderes macht und was dieses andere ist.

Im Sinne des Clean Codes ist daher das Abonnieren außerhalb eines Konstruktors zu realisieren.