Chain response handlers

[Ryan Mason-Davies]

Follow on from #16.

For me, composition always wins over inheritance. Chaining response handlers (responders?) would open up the doorway to some pretty cool stuff.

A good use case would be chaining a JSON parser to a responder which updates values on some model. The client wouldn't need to know about parsing JSON - it would essentially result in object mapping (which RestKit heavily relies on.)

Chaining diagram:

Request --> Selective Discarder --> JSON Parser --> Object Mapper

The client would then join the dots, fire a request, and that's it. SRP in action. Very similar to Apple's chain of responsibility, and to the Decorator design pattern.

Progress handling and error handling might also benefit from a similar pattern, e.g:

Request --> Selective Discarder --> Percentage Calculator --> Update Label (domain specific - deals with UI)

Or for errors:

Request --> Selective Discarder --> Error Localizer --> Alert Presenter (again, domain specific)

It would be necessary to have a concept of a compound response handler - one which forwards messages to multiple responders but appears as one object to the request - to handle responses differently:

Request --> Compound Handler --> Percentage Calculator --> Update Label
                            \--> Progress Bar Updater

I'm not sure how usable this would be to those uncomfortable with constructing a larger number of objects, or how difficult it would be implement. I have a feeling it's largely my preferred coding style leaking out, and that the best solution might be a compromise.