Board index » delphi » Diamond back refactoring (again, I know...)

Diamond back refactoring (again, I know...)


2004-09-24 01:44:45 AM
delphi270
Hey,
I do not know if this has been discussed or answered in here, as in
there's like a couple of hundred messages each day which I do not
always read so please direct me to relevant id's if so, but will
diamondback include any class level refactoring ?
I'm especially interested in the following:
"Extract SubClass"
www.refactoring.com/catalog/extractSubclass.html
"Extract SuperClass"
www.refactoring.com/catalog/extractSuperclass.html
Also (or rather, even more) an "Extract Ancestor Class" type
refactoring where, given some highlighted, methods an ancestor class is
created along with dependent fields, properties and methods placing
these in at least protected scope.
And, since the editor does not support highlighting of lines that are
non successive, an "Extract/Migrate to class" type refactoring where a
method is migrated to a selected class along with it is dependents.
Regards,
Johnny
--
The universe is a big place, perhaps the biggest.
- Kilgore Trout
 
 

Re:Diamond back refactoring (again, I know...)

Quote
will diamondback include any class level refactoring ?
We only know what's in it now. There is support for Rename
Method/Variable/Parameter/Class/Namespace/etc,
Extract Method, and Extract Resource String (Like Replace Magic Number
With Constant).
Extract Method is the most important one, IMO. I know there are a lot
Corbin would like to do, so we'll have to see.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper XXXX@XXXXX.COM
Falafel Software www.falafelsoft.co.uk
_______________________________________________
 

Re:Diamond back refactoring (again, I know...)

On 23-09-2004 Jim Cooper writes:
Quote

Extract Method is the most important one, IMO. I know there are a lot
Corbin would like to do, so we'll have to see.

Agreed.
Especially when writing libraries renaming in a non local scope is more
damaging than useful. Extracting a method will by default occur on a
local scope and be of no harm in that context.
The first two class level refactorings I mentioned, "Extract SubClass"
and "Extract SuperClass", are potentially harmful as well. The extract
ancestor class should be safe though.
Even so I must say I find renaming quite useful, in a non library
context, since classes are merely specialized fragments of a greater
whole and thereby easily subject to change (if just by name).
Regards,
Johnny
--
Experience is that marvelous thing that enables you to recognize a
mistake when you make it again.
- Franklin P. Jones
 

Re:Diamond back refactoring (again, I know...)

Quote
Especially when writing libraries renaming in a non local scope is more
damaging than useful.
I'm sure I have missed your point here. Why is that so? The Rename
refactoring only renames what it should. it is not the old search and
replace, but a smart, context-aware version. AFAIK it won't cross
project boundaries though (or maybe project group boundaries if you have
them)
Or are you talking about changing the public interface? In that case,
then yes, but that is an issue for you no matter what refactoring you do,
either by hand or mechanically. There are a number of issues with
refactoring generally. that is one, the other big one for some people is
that the Fowler refactorings are not thread-safe (necessarily). There
are others.
Quote
Extracting a method will by default occur on a
local scope and be of no harm in that context.
The extracted method is made protected, if that is what you mean.
Although adding to a public interface is not necessarily bad.
Quote
The extract ancestor class should be safe though.
I must confess I didn't see the difference between that and Extract
Superclass :-)
Quote
Even so I must say I find renaming quite useful, in a non library
context, since classes are merely specialized fragments of a greater
whole and thereby easily subject to change (if just by name).
Yes, it is useful, and it works on much more than class names too.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper XXXX@XXXXX.COM
Falafel Software www.falafelsoft.co.uk
_______________________________________________
 

Re:Diamond back refactoring (again, I know...)

Quote
>Especially when writing libraries renaming in a non local scope is more
>damaging than useful.
Fully agreed. But in some cases it is OK and intended.
Quote
I'm sure I have missed your point here. Why is that so? The Rename
refactoring only renames what it should. it is not the old search and
It cannot always do that: I have watched the last few weeks while
working on some code and found that you need both:
full context aware replace and limited to a certain scope only.
When implementing a new method I sometimes start with a copy of an existing method
and rework that as required. it is in these cases where you certainly do not want
a full rename: what if the new method should work on a different field, call different methods
but in the same "pattern"?
assume field FOriginal and method DoOriginal
procedure TSample.OriginalMethod;
begin
if Valid then
FOriginal := DoOriginal
else
FOriginal := 0;
end;
procedure TSample.CopiedMethod;
begin
if Valid then
FOriginal := DoOriginal
else
FOriginal := 0;
end;
The intend of this method is to do something SIMILAR, but not on the fields
FOriginal and method DoOriginal: instead it shoudl operate on FNew and DoNew
liek this:
procedure TSample.CopiedMethod;
begin
if Valid then
FNew := DoNew
else
FNew := 0;
end;
In this simple case it is easy to change by hand but in more complex cases
you'd want a Rename that is limited to Local Scope.
Invoking a find references and rename in CopiedMethod would
also affect the OriginalMethod and the original fields. Which is what you do not want.
That's why I use ModelMaker Code Explorer's "Rename local" refactoring
combined with the DB Rename refactoring.
In fact in the above example I'd first use
RenameLocal FOriginal =>FNew
then AddField (put cursor on FNew, press Ctrl+Alt+F)
then RenameLocal DoOriginal =>DoNew
then AddMethod ((put cursor on DoNew, press Ctrl+Alt+M)
all available in Delphi 5-8 and DB with ModelMaker Code Explorer.
Gerrit Beuze
ModelMaker Tools
 

Re:Diamond back refactoring (again, I know...)

Quote
It cannot always do that:
Yes it can (but AFAIK the code needs to compile first).
Quote
It's in these cases where you certainly do not want
a full rename:
Cases like that are not refactorings. You're adding new functionality,
not restructuring what you have. But it is a good example of when to use
SyncEdit on compilable code. I had not thought of an occasion to use it
like that.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper XXXX@XXXXX.COM
Falafel Software www.falafelsoft.co.uk
_______________________________________________