Diskussion:Zuständigkeitskette

Vor- und Nachteile

Es gibt auf der anderen Seite keine Garantie, dass die Anfrage tatsächlich bearbeitet wird. Wenn das letzte Glied der Kette eine Anfrage erhält, für die es ebenfalls nicht zuständig ist, wird die Anfrage nach obigem Muster verworfen. Dies muss durch eine entsprechende Fallbehandlung abgefangen werden.

Wenn der Bearbeiter für eine bestimmte Anfrage fehlt das liegt es daran, dass es ein Bug ist oder das Softwareprojekt noch nicht fertig entwickelt ist oder die Kette für diese Anfrage nicht gedacht ist. Aber das ist doch kein Nachteil des Design Patterns? (nicht signierter Beitrag von Blubbi1234 (Diskussion | Beiträge) 11:48, 25. Sep. 2015 (CEST))

Jein. Es ist nicht zwangsweise ein Nachteil. Manchmal ist das Verhalten auch gewünscht. Es ist aber eine wichtige Eigenschaft des Patterns. Außerdem kann die genannte Eigenschaft durchaus ein gewaltiger Nachteil sein, etwas das man bedenken sollte, wenn man eine CoR einsetzen will. Gesetzt den Fall, dass das hinten Runterfallen nicht gewünscht ist, beinhaltet das Pattern die Gefahr, dass eben genau das passiert. Das ist quasi ein Fallstrick, eine potenzielle Problemstelle. Das ist wie, wenn ein Bauteil prinzipbedingt eine scharfkantige Stelle hat. Man kann sich daran schneiden und das wäre dann das physische Äquivalent eines Bugs. Aber die scharfe Kante an sich ist eben ein Nachteil des besagten Bauteils. Man muss sich nicht schneiden, aber allein die Tatsache, dass es möglich ist, stellt einen Nachteil dar, den man bedenken sollte und der es beispielsweise ungeeignet für Kinderspielzeug macht. --Der Hâkawâti ✉ 20:01, 25. Sep. 2015 (CEST)

Selbst die Kettenglieder müssen nur ihren direkten Nachfolger und nicht den Gesamt-Aufbau der Kette kennen. Dies führt zu einer geringeren Kopplung. 

Es muss sichergestellt werden, dass jeder Bearbeiter in der Kette nur einmal vorkommt, sonst entstehen Kreise und das Programm bleibt in einer Endlosschleife hängen.

Dass jeder Bearbeiter (üblicherweise) nur einmal in der Kette vorkommen soll, ist verständlich. Aber warum sollen Kreise entstehen, falls ein Bearbeiter zwei Mal in der Kette vorkommt? Es hängt davon ab, wie die Kette Implementiert ist.

Wenn man die Verkettung vernünftig einsetzt, nimmt man mit großer Wahrscheinlichkeit eine fertige Klasse (etwa wie List<Bearbeiter>). Dann kann die Kette ruhig aus zehn Glieder bestehen und jeder Glied denselben Bearbeiter beinhaltet - es entstehen keine Kreise. Die Idee, den Kettenaufbau durch die Eigenschaften der Bearbeiter-Klasse zu implementieren, passt irgendwie nicht in die Beschreibung von GoF Muster (wir sprechen doch über die ObjektOrientierte Welt) und ist auf keinen Fall Bestand dieses Musters, obwohl das buchstäbliche Lesen des UML Diagramms zu solchem naiven Gedanken führen könnte.

Dazu auch gehört die Passage, dass Selbst die Kettenglieder müssen nur ihren direkten Nachfolger und nicht den Gesamt-Aufbau der Kette kennen. Dies führt zu einer geringeren Kopplung. Was hat Implementierung einer Kette mit diesem Muster zu tun? Es ist irritierend und kann als die Idee empfunden werden, das Link auf den nächsten Kettenglied in die Klasse Bearbeiter einzubauen (ja, ich kenne das Code-Beispiel von GoF zu diesem Muster. Bitte berücksichtigen, im welchen Jahr die dieses Beispiel erarbeitet haben). Dies würde eben zu einer stärkeren Kopplung führen. Und falls diese Idee nicht gemeint wurde, von welcher Kopplung ist in diesem Kontext die Rede?

Falls man doch die Klasse Bearbeiter mit Aufgaben überlastet und das Link auf den nächsten Bearbeiter buchstäblich in die Klasse einbaut (hallo SRP), bin mal gespannt, wie man einen Kreis in der Kette im Code implementiert... (nicht signierter Beitrag von 62.225.75.26 (Diskussion) 15:42, 6. Mai 2021 (CEST))