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.
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:
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:
Or for errors:
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:
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.