| Summary: | Encapsulate Field Refactoring does not implement the "get" method | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Melina Mongiovi <melmongiovi> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | noopur_gupta, stephan.herrmann |
| Version: | 4.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
Counterpoint: I have a Pair class which provides a getter in addition to a field to allow the field's value to be retrieved using a method reference. I'm also using a naming convention which drops the get-/set-prefixes from getters/setters:
public class Pair<L, R> {
public final L lhs;
public final R rhs;
public R rhs() { return rhs; }
public L lhs() { return lhs; }
// etc..
}
In this case I would not expect Encapsulate Field to mess with the existing getters. Please note that while the getters or the class itself are not abstract like in your example, they are not final either.
Same reason as bug 471961 comment #2. If you still want to create a new getter/setter, you can edit the name of the getter/setter being created in the Encapsulate Filed dialog. (In reply to Noopur Gupta from comment #2) > Encapsulate Filed dialog. Encapsulate Field dialog. I would suggest to include a warning message to the user before applying the refactoring, alerting him that there is already a "getF" method and the tool will not create a new method to return the field value. Notice that in large programs, the user may not remember about all existing methods. |
The class under refactoring has an abstract method "getF". Applying the Encapsulate Field Refactoring in the field f, the transformation does not implement the "get" method. Before Refactoring: abstract class A { public abstract int getF(); public int f = 10; } Resulting Program: abstract class A { public abstract int getF(); public void setF(int f) { this.f = f; } private int f = 10; }