From: Egon W. <eg...@us...> - 2005-08-27 21:59:50
|
On Thursday 25 August 2005 03:38, Rich Apodaca wrote: > On Wed, 24 Aug 2005 21:09:56 +0200, Egon Willighagen wrote > I like the approach of separating interfaces from implementaitons :-). My main obstacle with is was the effect of having funny names... List vs. Vector is reasonable (java.util), but Atom vs AtomImpl (as in Jumbo) or AtomInterface vs Atom did not sounds very obvious... Anyway, last week I realized that it had to be possible to have Atom vs Atom, using two different packages... weird that it took my about 8 years to come to that solution :( > I think your experience suggests that this could be a much bigger job than > it seems at first glance. This is in full agreement with my past experience > doing refactorings like this. So far, it has been smoothly... the next phase kids in now, which will take more refactoring: have method return interfaces instead of classes. > Here's a process I use. There are many effective ways to do this, so I > offer mine if you think it can help: > > (1) Make the refactoring effort independent of the main development tree if > it isn't already and give it a unique name (CDK2?) and a unique development > tree. This keeps the "old" tree working no matter how rough the refactoring > gets and allows bugfixes and releases to continue on the "old" tree. Well... the idea right now is slightly different... there is no real API change, except for the fact that people have to use different import clause: import org.openscience.cdk.interfaces.Atom; instead of: import org.openscience.cdk.Atom; Methods etc. do not change at all, not even in name. In other words, users *and* developers should not even notice much difference. > (2) Develop all of the interfaces that will be used with complete > documentation including all thrown RuntimeExceptions. The documentation is > essential - not so much for end users, but for myself. If I ever have > trouble documenting an interface or one of its methods, it usually means > I've got the design wrong. I spend most of my time on this step because it > is a lot easier to rewrite an interface definition than to rewrite an > implementation. Documentation for the data classes (and thus the interfaces) was proper addressed earlier, but very important indeed. > (3) Try to get feedback on the product of step (2). Does it address the key > problems the refactoring was supposed to solve? We've had 5 years of feedback :) > (4) Gradually implement interface methods. This can be as simple as copying > methods from the "old" tree, but often isn't. Write completely new unit > tests to verify the implementations work. Actually... it's better to first write the unit tests, and only then port the old implementation. > (5) Iteratively add in more and more of the "old" implementations or write > new implementations in small chunks by repeating step (3). > > (6) Add in old functionality not part of the refactoring. Eclipse is a > wonderful tool here because it lets me interactively fix compiler errors. Yes, nice IDE indeed. A bit sluggish in some points... Editing validating XML docs in jEdit is way faster... > (7) Have a beer (or two)! Cheers! Egon -- eg...@us... GPG: 1024D/D6336BA6 |