 |
As the new Java.net infrastructure contains project-level wikis, this main wiki will be shut down in the near future. For wiki page export and general wiki questions please contact the site admin at communitymanager@java.net. Refactoring
The process of rearranging source code into a new form that functions (more or less) the same but may be more readable, more modular, more reliable, etc.
Many tools exist to refactor Java source code easily, for example:
Books
- RefactoringBook by Martin Fowler - This is sort of the definitive work on the subject. Very well written catalog of refactorings. Almost all of them seem really intuitive, as you would hope.
- RefactoringToPatterns by Joshua Kerievsky is another great collection of code transformations, albeit at a higher level..
Articles
Collected refactoring topics
Discussion about Refactoring
-- Main.rickcarson - 19 Apr 2004
A little design saves a lot of refactoring.
While it is true that: Bad design < No design
It is also true that: No design < Good design
Design is thinking about how everything fits together, to provide coherency, a common paradigm for what the code is trying to achieve.
If you understand the design and problem space, you have a much better ability to tweak the right thing and do little things that make big, well controlled, changes. (Of course - any process of change is enhanced by having good test cases)
Whereas refactoring without understanding the big picture runs the danger of introducing small subtle defects that avalanche out of control.
Here's some signs that someone shouldn't be doing the design:
- They don't like interfaces
- They don't like 'protected' (clear sign they are uncomfortable with inheritance)
- They like 'static' and 'final' a bit too much
- They don't write with subclassing in mind
- They prefer broad shallow class hierarchies to deep ones (ie prefer to reinvent the wheel rather than reuse code)
Make sure to refactor towards the good things rather than away from them. For example:
- If two objects do similar things, the quick and easy thing to do is to whip up a third class that they can delegate to ('has a') - but perhaps they really ought to be subclasses of a common class ('is a'). Why is the second sometimes better? Because sometimes with the first you end up with a lot of 'From Collection C pull out Object O - if its an A, do A.X, - if its a B do B.X' style code. Instead of that, you could pull out the object, cast it to the common interface and call the method on that. In addition to being shorter, you then have the ability to add a third type later on, and the code still goes, whereas in the first example you need to manually add in the third case.
- Static can be bad, particularly large classes mostly consisting of static methods (ie a library). While this is a quick and dirty way to design, the disadvantage of using a massive class chock full of static methods is that you cannot replace it. You will have effectively hardcoded into your code the method call. Performance is no reason to make the method calls static, because you should assume that the compiler and hotspot will do funky things to speed it up anyway. (Making methods static is often a classic case of premature optimization) Whereas if you made them un-static, and had an instance of the class - you could later on use subclassing and replace the original class (possibly on the fly even!) if you need to change the behaviour at some later point. The cynical amongst us will recognise that requirements which change once are likely to be changed again (or changed back) - in those cases its nice to be able to 'perform miracles' just by swapping out one 'library' for another (the deeply cynical will not 'fess up to having made the change and will use the 'breathing space' to refactor other more important parts of the code (the ultimate in cynicism is to not make the change at all, on the theory that either noone will notice it anyway or that it will just change back again soon or later anyway)) . This is more an 'engine' based approach, and is quite powerful, and done right actually requires less work than a library, certainly a lot less than building and maintaining the large toxic code dumps which libraries often become.
|