Re: [PATCH] Make URN support an optional component

On Sun, 2006-08-27 at 21:24 +0800, Adrian Chadd wrote:
>
> Its a good goal. The trouble is that you're creating new APIs just by
> refactoring. It might be easy to change the API(s) at the point
> you've
> done the refactoring but I don't think it'll be so easy to do later on
> as other code is brought into line to use the new API(s).

Ah - I see your concern. My answer is that its a lot easier to change
code with unit tests than code without - because you can be sure of the
impact of your changes.

Also the techniques for rapid refactoring [see Martin Fowler:
Refactoring] will apply to the code I've written - they dont to much of
the current code, because its hard to tell if something has been broken.

For instance, If you want to move the logic I'm putting into URLScheme
into HttpRequest making HttpRequest have subclasses for each protocol
(this is another valid approach - it might be better, I dont know),
theres a series of correctness preserving transforms that will do that
quite handily:
 - create tests for each subclass that should exist, and create the
subclasses
 - move the existing urlscheme tests to test instances of the http
request subclass, testing the same behaviours - this will involve
ensuring all the methods are exposed on httprequest.
 - make the urlscheme of the request private
 - move the functionality from the url scheme onto the new methods of
http request, in the right subclasses.
 - delete urlscheme and any remaining tests

This has the key properties that:
 * each step is very small and easy to understand.
 * you can stop at any point and the code will still run.

These two properties combine to make it really trivial to rearrange
code.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.