Was ist der Unterschied zwischen dem Design-Pattern Chain of Responsibility und einem einfachen if-elseif-else-Block?

Question

Ich habe gerade die Chain of Responsibility neulich gesucht und bin auf this Beispiel gestoßen.

Grundsätzlich gibt es einen abstrakten Handler, und dann sind konkrete Handler, von denen jeder die Handle-Methode des übergeordneten abstrakten Handlers implementieren. Die Implementierung ist so, dass zuerst geprüft wird, ob dieser bestimmte Handler die aktuelle Anfrage verarbeiten kann, und wenn nicht, gibt er die Anfrage an seinen Nachfolger weiter.

Jetzt könnte ich auch das gleiche mit einem einfachen if-else-bedingten Block machen. So nehmen Sie das erste Beispiel aus den obigen Link, hier ist, wie ich es ändern:

class SingleHandler 
{ 
    if(request > 0 && request <= 10) 
    { 
     // Process request 
    } 
    else if(request > 10 && request <= 20) 
    { 
     // Process request differently 
    } 
    else if(request > 20 && request <= 30) 
    { 
     // Process request differently 
    } 
} 

Nun, meine Frage ist, was ist der grundlegende Unterschied zwischen den beiden? Gibt es einen bestimmten Grund, warum ich die Chain of Responsibility überhaupt verwenden sollte, wenn ich die gleiche Funktionalität mit if-else-Blöcken bereitstellen kann? Was ist besser in Bezug auf Leistung, Speicherverbrauch, Wartbarkeit, Skalierbarkeit?

Answer 1

Ja, Sie könnten dieses Beispiel neu schreiben, um mehrere if-else-cascades zu verwenden. Aber nur weil es ein einfaches Beispiel ist.

Die Kette der Verantwortlichkeit ist ein dynamisches Muster. Das bedeutet, dass Handler während der Laufzeit ausgetauscht werden können. Dies wird häufig in UI-Code getan, wo mehrere verschachtelte Steuerelemente die Handler darstellen können. Stellen Sie sich folgendes Szenario vor:

Sie haben ein Fenster. In diesem Fenster gibt es eine Art von Panel. In diesem Panel befindet sich ein Textfeld. Sie klicken mit der rechten Maustaste auf das Textfeld. Der ausgeführte Befehl hängt von der Hierarchie ab. Das System würde den ersten Handler - die Textbox - bitten, die Klickanfrage zu bearbeiten. Wenn es nicht weiß, was mit der Anfrage zu tun ist, übergibt es es an seine Eltern - das Panel - usw. Ich bezweifle, dass Sie diese Art von Szenario mit einer Wenn-sonst-Kaskade implementieren möchten. Jedes Mal, wenn Sie die Benutzeroberfläche ändern, müssten Sie die Kaskade ändern. Aus diesem Grund werden Handler-Objekte verwendet. Es macht den Code austauschbar und wiederverwendbar.

Viele Muster können auf andere Weise implementiert werden. Dies ist in Low-Level-Programmiersprachen ohne Objektorientierung üblich. Diese Codes sind jedoch normalerweise sehr unflexibel und schwer zu warten. Aber das ist es, was sie schnell macht.