First of all, thanks for writing this book, when I look at the book reviews this seems to be one of the must have books. So congrats on the 10 horseshoes from javaranch.
When I looked at the manning publishers website (http://www.manning.com/forman) it shows there are a couple of chapters up for download. Yesterday the links did not work, today they do. And I agree, it is a nice read.
So obviously this brings me to my working situation, to try and bring some of it in practice. I currently work in a location that could help with a lot of refactoring. My question is, are there any chapters on refactoring with reflection ?
swimming certificate (A & B), shoelaces diploma, and some useless java ones.
Friso, It depends on how strictly you define refactoring. The definition states that refactoring improves the design without changing the interface. Reflection would tend to widen the interface. So it is more like development than true refactoring.
What I have in mind is the following: changing switch case statements into a reflection orientated design like mentioned in book : 'Refactoring: Improving the Design of Existing Code' - 'martin fowler'.
I would like to know if the reflection in actin book described more refactoring issues.
Originally posted by friso dejonge: What I have in mind is the following: changing switch case statements into a reflection orientated design like mentioned in book : 'Refactoring: Improving the Design of Existing Code' - 'martin fowler'.
What actually is reflection orientated design, friso? Could you give us a hint about it? I have not got a chance to have a look at that book of "Martin Fowler"... Thanks...
Sometimes my memory is bad, but i cannot remember such a suggestion in Fowler's book. Switch statements are usually refactored using command pattern, but who knows, maybe reflection can be applied too.
The Java refactoring tools rely heavily on static typing to implement the automated refactorings they have today. That kind of things are much more difficult to ripple to code that uses Reflection.
Consider an otherwise simple refactoring like Eclipse's Change Signature, which allows you to reorder/add/remove a method's arguments using a wizard. Eclipse can easily interrogate the abstract syntax tree of all your source code to locate places which reference that particular method and swap/add/remove arguments in all those places as appropriate. Now, if you've got a piece of code that uses a dynamic proxy with the Reflection API, that information is not present in the abstract syntax tree. Instead, there's a generic method invoke(Object proxy, Method method, Object args) and the information about the arguments' order or count is buried in the method's body -- something Eclipse does not know enough about to go and tweak on its own.
In general, the way that I've found most effective in getting rid of switch statements/deluges of if's is to use polymorphism and delegation. One realization of this is the Command pattern that Ali refers to. The GoF book (Design Patterns) is, of course, a great resource for this. Another that I like, especially for Java programmers, is "Design Patterns Java Workbook" by Steve Metsker.
Here's the basic design approach. Set up an interface with a method that takes the data used in the body of your switch cases. Implement the interface with handler classes that each contain the logic of a single switch case. Use a factory method to construct instances of your handler classes, and pass those handlers your data.
So far, we've seen no reflection in this discussion. Add dynamic loading and reflective construction to your factory method and you open your application up to anything you might write or integrate in the future.
For more discussion of the dynamic loading and construction, see this thread: