I am currently working on USB firmware for a project. While figuring out how to best handle servicing requests from the host, I decided to implement a Chain of Responsibility pattern.
In my application, there will always be exactly one handler for each request retrieved from the host. So basically I set up my handler chain ahead of time and the loop starts with waiting for a request from the host. The request is passed to the "root" handler who decides, by examining part of the request, whether to handle it or pass it down the chain. Once the request is handled, we loop back to waiting for another request from the host.
Again, only one handler will ever handle a request. A request not being handled, i.e., traversing the entire handler chain, is an error condition.
After reading up on the Chain of Responsibility pattern from www.sourcemaking.com, this quote caught my eye (last paragraph in the Discussion section):
Do not use Chain of Responsibility when each request is only handled by one handler, or, when the client object knows which service object should handle the request.
Is there a good practical reason why this is true? It seems to me that using Chain of Responsibility in the case the author warns against is perfectly valid. Could anyone give me some insight on why this would be a bad design choice?
Aucun commentaire:
Enregistrer un commentaire