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>.
signature.asc
Description: This is a digitally signed message part
