196 }
197
198 @Override
199 protected SoundEvent getHitSound() {200 return SoundEvents.ITEM_ARMOR_EQUIP_IRON;201 }202
203 @Override
204 protected void onBlockHit(BlockHitResult blockHitResult) {
160 }
161
162 @Override
163 protected SoundEvent getHitSound() {164 return SoundEvents.ITEM_ARMOR_EQUIP_IRON;165 }166
167 @Override
168 protected void onBlockHit(BlockHitResult blockHitResult) {
182 }
183
184 @Override
185 protected SoundEvent getHitSound() {186 return SoundEvents.ITEM_ARMOR_EQUIP_IRON;187 }188
189 @Override
190 protected void onBlockHit(BlockHitResult blockHitResult) {
218 }
219
220 @Override
221 protected SoundEvent getHitSound() {222 return SoundEvents.ITEM_ARMOR_EQUIP_IRON;223 }224
225 @Override
226 protected void onBlockHit(BlockHitResult blockHitResult) {
48 return this;
49 }
50
51 public AbstractRangedAttack setSound(SoundEvent sound, float volume, float pitch) {52 this.sound = new AttackSound(sound, volume, pitch);53 return this;54 }55
56 public AbstractRangedAttack setAccuracy(double accuracy) {
57 this.accuracy = accuracy;
Getter or setter methods must not perform operations other than reading or writing fields they are named after.
The main purpose of a getter is to allow easy access to private fields that the programmer wants to expose. Setters are, similarly, meant to allow users of a class to set the values of private fields.
When working with multiple fields that all need getters and/or setters, it is easy to make the mistake of just copy-pasting the same method, and forgetting to change the field that is returned/assigned, or forgetting to change the name of the method. Such mistakes can cost a great amount of time to find.
This issue is raised when:
private SomeClass something;
private String privateString;
// This method appears to get something, but returns privateString!
public String getSomething() {
return privateString;
}
// This method seems to set privateString, but instead sets some other value!
public void setPrivateString(int value) {
someInt = value;
}
Getters and setters work because of the assumed method contracts, that API consumers can get or set the value of the field represented by the method's name.
Always name getters and setters based on only the field they are reading or writing to.
private String someString;
private int y;
public void setSomeString(String val) {
someString = val;
}
public int getY() {
return y;
}
A method that has the same name as a field, but performs some action other than getting or setting that field may benefit from renaming the method to avoid ambiguity for both API consumers as well as for future developers.
// public class MediaPlayer
private ArrayList<Song> queue;
// This method looks like a getter but it instead does something else...
public void queue(Song s) {
queue.add(s);
}
Consider renaming the method to be more appropriate in such cases.
// The operation performed by this method is now very clear;
// we are enqueueing a new song into the queue.
public void enqueue(Song s) {
// ...
}