Encapsulate Fields
The Encapsulate Fields refactoring lets you hide your data and create the necessary accessors.
Hiding your data and accessing it through an outward interface based on accessor methods is a good idea. Later you can change the data internals, preserving full compatibility with the code relied on the class and its available methods.
In the editor, place the caret at a class or at the desired field or at any place inside the class you want to refactor. (You can also use the Project tool window or Structure View for your selection.)
On the main menu or on the context menu, select .
In the dialog that opens, check the fields to which you want to create accessors, specify whether you want to create getter or setter methods. Plus, select the Use accessor even when field is accessible if you want to replace all field occurrences with the calls to the appropriate accessor method. You can also select visibility options.
Examples
Before | After |
|---|---|
//File Class.java
public class Class {
public String aString;
}
|
//File Class.java
public class Class {
private String aString;
public void setaString(String aString) {
this.aString = aString;
}
public String getaString() {
return aString;
}
}
|
//File AnotherClass.java
public class AnotherClass {
public Class aClass;
public void method() {
aClass.aString="string";
}
}
|
//File AnotherClass.java
public class AnotherClass {
public Class aClass;
public void method() {
aClass.setaString("string");
}
}
|
Encapsulate fields dialog
Use this dialog to specify options for the Encapsulate fields refactoring.
Item | Description |
|---|---|
Fields to encapsulate | In this area select the fields you want to create accessors for. You can accept the default method names or change them at will. If a method with the same signature is already present in the class to be refactored, the Method icon |
Get access/Set access | Use this option group to select which accessor methods (Getter, Setter or both) will be created for the selected fields. If one of the checkboxes is cleared, the entire corresponding column (Getter or Setter) in the Fields to Encapsulate table is disabled. |
Encapsulated Fields' Visibility | Here you can specify the new visibility scope for the selected fields |
Options | Select whether you want to use accessors even when field is accessible or not. If the option Use accessors even when the field is accessible is not checked, the references to the desired fields, when the fields are directly accessible, will not change. Otherwise, all references to the desired fields will be replaced with the accessor calls. It also depends on your selection in the options group Encapsulated Fields' Visibility. For example, if you uncheck the option Use accessors even when the field is accessible, and select the private visibility for the fields, the usages of the fields outside the class will change, but within the class they will remain the same. |
Accessors' Visibility | In this area select the visibility scope for the created accessor methods. |
appears to the left of the accessor name, along with the corresponding visibility icon. No new accessor method will be created in this case. The existing method will not be changed and, generally, nothing else will be additionally checked. In this case you have to be attentive whether the existing method actually functions as an accessor. Otherwise, you might need either to choose another name for the accessor or to go back to the editor, change the existing method and only then invoke the Encapsulate Fields refactoring again. If the existing method overrides/implements a parent class' method it will also be marked with the Overrides method 
or Implements method 
icon. If the accessor method does not exist in the class to be refactored but, if created it would override/implement a method of the parent class such method will be marked with the Overrides method