Bugzilla – Full Text Bug Listing
| Summary: | Encapsulate Field refactoring does not implement a correct "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: | |||
Perhaps the meaning of "f" is "work-units remaining to be consumed" and in this implementation all work-units are immediately consumed upon receipt without actually doing any work on them, making this implementation a "null-implementation". It would be bad for Encapsulate Field to change such a null-implementation in ways that make it not-a-null-implementation. This is as expected. We use local getter/setter if it already exists. (In reply to Noopur Gupta from comment #2) > This is as expected. We use local getter/setter if it already exists. I suggest you to report a warning message to the user before applying the refactoring. Then, the user can decide about leave the class abstract or not. |
When encapsulating a field, it does not implement a correct "get" method. The program has a "get" Method returning 0. After the transformation to encapsulate field A.f, the getF still returns 0 instead of "f". Before Refactoring: public class A { int f; public int getF(){ return 0; } } Resulting Program: public class A { private int f; public int getF(){ return 0; } public void setF(int f) { this.f = f; } }