see : FeatureRequests, OnFeatureRequests
If you have a bright idea about a new refactoring that can be added to IntelliJIDEA for everyone's benefit, you are welcome to put it here.
Hint: you might want to discuss it first on news:jetbrains.intellij.features or news:jetbrains.intellij.eap.features so that the whole community may contribute to the suggestion.
Note : use <tt><pre>..</pre></tt> around code samples (to make it look good on Netscape too  )
<--
Proposer: NathanBrown
(top)
Support lazy initialization in the the "Encapsulate fields" refactoring when an initialization statement exists at the field declaration and the field is of an object type.
Using this option, the existing initialization would be moved into the get method so that :
private Object _value = new ExpensiveObject();
would be transformed to
private Object _value;
public Object getValue()
{
if (_value == null) {
_value = new ExpensiveObject();
}
return value;
}
As initialization of fields is done in the construction of an object it is inherently thread safe. Moving to lazy initialization means that thread safety must be considered, something which novice programmers (or lazy advanced programmers  ) may not do.
Potential Solutions:
- Provide an option (selected by default) to synchronize lazy initialization methods.
- Place a warning comment into the get() method; e.g.
// @todo : This method's thread safety must be evaluated.
| I would use this .. | |
|---|
| very often | 0 | . |
| occasionally | 4 | xxxx |
| rarely | 2 | xx |
| never | 1 | x |
Proposer: AlainRavet (top)
Provides an easy way to rewrite one form into the other.
| if/else | <<-->> | ternary operator |
String s ;
if (condition) { s = "trueS" ; }
else { s = "falseS" ; }
|
<<-->>
|
String s = (condition ? "trueS"
: "falseS") ;
|
| I would use this .. |
|---|
| very often | 0 | . |
| often | 0 | . |
| occasionally | 6 | xxx |
| never | 0 | . |
http://www.refactoring.com/catalog/extractClass.html / http://www.refactoring.com/catalog/inlineClass.html
Extract Class can be performed in two steps: Extract Super Class, Replace Super Class With Delegation, both already implemented. Since the inverses do not exist, Inline Class cannot be done in this fashion.
DwightRodgers 21 Jun 2003
| I would use this .. | Extract | Inline |
|---|
| very often | 6 | xxxxxx | 1 | x |
| often | 1 | x | 2 | xx |
| occasionally | 1 | x | 5 | xxxxx |
| never | 0 | . | 0 | . |
http://www.refactoring.com/catalog/replaceMethodWithMethodObject.html
Just in case you have a method big enough to be its own object.
I've attached a rudimentary implementation of this refactoring (using Psi). It's one of the ones I thought was important enough to implement myself a while ago. However, for simplicity, I don't promote any of the local variables to fields by default -- since this action is already an implemented refactoring. I use the one that I've attached, followed by local->field and extract method until I have the code the way I want it. Then I may move the class to non-inner level, if it has no dependencies and doesn't belong inside. Let me know if you'd like me to rewrite it to behave differently.
If you don't work for JetBrains, note that the code uses Psi and therefore is unlikely to work, and no one claims any responsibility for anything. If you do work for Jet Brains please take my code and use it for your commercial purposes. If my code is not written in the way that you would like refactorings to be written, please give me advice, and I will write them better next time.
DwightRodgers 21 Jun 2003
| I would use this .. |
|---|
| very often | 0 | . |
| often | 0 | . |
| occasionally | 4 | xxx |
| rarely | 3 | xxx |
| never | 0 | . |
http://www.refactoring.com/catalog/replaceDataValueWithObject.html
| I would use this .. |
|---|
| very often | 0 | . |
| often | 3 | xxx |
| occasionally | 4 | xxxx |
| never | 0 | . |
http://www.refactoring.com/catalog/replaceConstructorWithFactoryMethod.html
This would replace all new XXX() by XXX.newInstance().
| I would use this .. |
|---|
| very often | 0 | . |
| often | 2 | xx |
| occasionally | 5 | xxxxx |
| never | 1 | x |
http://www.refactoring.com/catalog/replaceParameterWithMethod.html
| I would use this .. |
|---|
| very often | 0 | . |
| often | 3 | xxx |
| occasionally | 3 | xxx |
| never | 0 | . |
Provide the ability to refresh the javadoc for a given element from the parent class/ interface
| I would use this .. |
|---|
| very often | 0 | . |
| often | 1 | x |
| occasionally | 0 | . |
| never | 1 | x |
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
| I would use this .. |
|---|
| very often | 0 | . |
| often | 3 | xxx |
| occasionally | 3 | xxx |
| never | 1 | x |
Replace Setter with CDI Parameter
(note Setter Depenency Injection = SDI & Constructor Depenency Injection = CDI)
A setter (SDI or not) can be replaced with a Constructor Dependency Injection parameter. The Constructors can be changed en masse, or duplicated. Setter can optiionally left in place.
See http://www.martinfowler.com/articles/injection.html
Also, for Resharper, Property is as applicable as Setter for this refactoring.
| I would use this .. |
|---|
| very often | 0 | . |
| often | 2 | xx |
| occasionally | 1 | x |
| never | 0 | . |
Add CDI Parameter for Field
(note Setter Depenency Injection = SDI & Constructor Depenency Injection = CDI)
A member variable/field can have a Constructor Dependency Injection parameter added for it. The Constructors can be changed en masse, or duplicated. Field can optionally go final. Consider:
class Apple {
final Orange orange;
Banana banana;
public Apple(Orange o) {
orange = o;
}
public Apple() {
orange = new DefaultOrange();
}
}
if banana were selected, and the 'add CDI parameter to ctor' were actioned, the result would be:
class Apple {
final Orange orange;
final Banana banana;
public Apple(Orange o, Banana banana) {
orange = o;
this.banana = banana;
}
public Apple(Banana banana) {
orange = new DefaultOrange();
this.banana = banana;
}
}
See http://www.martinfowler.com/articles/injection.html
| I would use this .. |
|---|
| very often | 0 | . |
| often | 2 | xx |
| occasionally | 1 | x |
| never | 0 | . |
| Before | <<-->> | After |
out.print("This ");
if (parrot) {
out.print("parrot");
} else {
out.print("dog");
}
out.print(" has ");
if (dead && parrot) {
out.print("ceased to be");
} else if (!parrot) {
out.print("no nose");
} else {
out.print("legs");
}
out.println("!");
|
<<-->>
|
out.print("This ");
if (parrot) {
out.print("parrot");
out.print(" has ");
if (dead) {
out.print("ceased to be");
} else {
out.print("legs");
}
out.println("!");
} else {
out.print("dog");
out.print(" has ");
out.print("no nose");
out.println("!");
}
|
The code above has been expanded for the 'parrot' condition - ie the
branches now extend over the entire extent of the code, and code which is
unreachable due to the enclosing condition has been refactored away. This
kind of repeated test of the same condition happens a lot in code where there's
been an attempt at avoiding duplication, but it makes it hard to extract a single
intent with 'Extract Method' or the 'Replace Conditional With Polymorphism'. I'd envisage
the refactoring working by selecting code that starts with a condition, the effect
being to expand that condition out to encompass the entire selection.
An alternate way of performing the refactoring would be to offer a menu of all
the boolean tests in the selection, check the ones you wish to expand and they will
all appear in all combinations in the new outermost condition, saving on repeated
refactorings. eg in the example above, expanding both conditions at once would give:
out.print("This ");
if (parrot && dead) {
out.print("parrot");
out.print(" has ");
out.print("ceased to be");
out.println("!");
} else if (parrot && !dead) {
out.print("parrot");
out.print(" has ");
out.print("legs");
out.println("!");
} else if (!parrot && dead) {
out.print("dog");
out.print(" has ");
out.print("no nose");
out.println("!");
} else {
out.print("dog");
out.print(" has ");
out.print("no nose");
out.println("!");
}
| I would use this .. |
|---|
| very often | 0 | . |
| often | 1 | x |
| occasionally | 0 | . |
| never | 1 | x |
CategoryIdeasAndSuggestions, CategoryPolls
|
|
