The document discusses the Chain of Responsibility design pattern. It provides examples of using the pattern for user authentication via different methods like email, local network login, and remote login. It also discusses pros and cons of the pattern, known uses including event handling, and provides a UML class diagram of the pattern with different handler classes for authentication.
5. This mass is available at https://gist.github.com/hlegius/e1a721ebbc7de2a91fb1
6. Code Review
•
•
•
•
•
•
•
We got a Service class;
Skinny Controllers;
Meaningful (and cool) names;
No temp variable;
Short methods;
A lot of non-sense `ifs` statements;
(Very) Complicated logic. (WTF award!)
9. WTF dude!?
Wrong design decision indicator!
This mass is available at https://gist.github.com/hlegius/e1a721ebbc7de2a91fb1
10. Chain of Responsibility
• Decouple client from receivers when you got
more than one object that can handle it;
• Giving you the chance to test each part
(sender and receivers) in isolated.
• Create one point of change if new Receiver
arrives.
• Added flexibility in assigning responsibilities to
objects;
• Boost your code readability like a boss.
11. This code is available at https://gist.github.com/hlegius/7188168
12.
13. This code is available at https://gist.github.com/hlegius/7188168
14. This code is available at https://gist.github.com/hlegius/7188168
15. Chain of Responsibility
Bad Consequences
• More Lines of Code than first version;
• Complex if you have one or two fixes
receivers;
• Receipt is not guaranteed that will be
handled;
16. Known Uses
• Handle Events – Also known as “Event
Handler” or “Responder”
• ET++ used Chain of Responsibility to handle
Graphical Updates. (Took from GoF book)
17. Macro point of view - UML
Client
UserAuthenticator
Handler
Authenticator <abstract>
ConcreteHandler1
EmailAuthenticator
ConcreteHandler2
NetworkAuthenticator
ConcreteHandler3
PartnerAuthenticator
18. Don't get me wrong!
You can apply this with
PHP, Python, Ruby and so on.