Community
Participate
Working Groups
As a big fun of refactoring, I like to "extract interface" from classes, but the UI lack a usefull button for searching the classes in the project class path. This kind of button is alreay implemented elsewhere in the UI. It's very very usefull! Another strage policy, I have never understand, is about the case where, if "MyInterface" already exist, I cannot re-extract from "MyClass" an updated "MyInterface" through the UI Dialog. I must delete first the old "MyInterface". The actual flow require me to: 1) delete the "old" compilation unit (file); 2) re-extract the "new" one; 3) compare the new with the old, copy back the important javadocs and constants I already write in; 4) save the merge; 5) repeat those steps for every extraction I need to update. Probably a good workflow could be to enter di "Extract Interface" Dialog, and like now (but through the search button too) perform the necessary step, and instead "ok", strike the (new) "preview" button that works ala compare-merge manner. Perhaps the dialog could be transformed in a two step wizard. I like very much this kind of improvements. Thank's in advance for your extraordinary work.
I am not entirely sure what your scenario is. As far as I understand, you would like Extract Interface to be more incremental. That is, the ability to extract methods to an already existing and implemented interface (therefore the search button for classes, right?). If an already existing interface is gets selected, the UI would only allow to check additional methods to be extracted. After this step, no additional UI is necessary (why compare-merge and a wizard?) But I like the idea as well.
(In reply to comment #1) > I am not entirely sure what your scenario is. As far as I understand, you > would like Extract Interface to be more incremental. That is, the ability to > extract methods to an already existing and implemented interface (therefore > the search button for classes, right?). > If an already existing interface is gets selected, the UI would only allow to > check additional methods to be extracted. After this step, no additional UI is > necessary (why compare-merge and a wizard?) > But I like the idea as well. Sure! That's right. Incremental is exatly what I'm looking for. But consider that we are refactoring so the UI should be flexible (or very interactive) to allow possibly syntax violations be solved inplace or, at least, after the end of the UI Dialog. Consider the case where I change the return type of a "void MyMethod()", and the "old" method definition still stay in the Interface to be updated. I should update the "old" method signature (old return type: void) with the "new" one (e.g. new return type: int), without losing anything like the Exceptions clause. That's because I suggest the "compare-merge" approach available in the "Team->Compare". In general, the incremental approach is more attractive at all, so please abuse about it every where, especially in the refactoring tools. ;) And probably the 3.1.1 release could be more attractive, instead the more later 3.2, if it may be possible... Thank's.
The scenario you are describing is not a refactoring. Refactorings are behavior-preserving code transformations from a consistent pre-state to a consistent after-state. We are not abandoning this principle. The refactoring Change Method Signature probably helps for the case described above.
(In reply to comment #3) > The scenario you are describing is not a refactoring. Refactorings are > behavior-preserving code transformations from a consistent pre-state to a > consistent after-state. We are not abandoning this principle. > The refactoring Change Method Signature probably helps for the case described > above. You are ok. Respecting the refactoring definition, it seems that the UI cannot allow the interface extraction incremental approach for that case. I have post not appropriate case. Sorry.
