Это плохая практика, чтобы мой метод getter изменил сохраненное значение?

на мой взгляд, если вы делаете lazy-loading (которого у вас нет в этом случае), геттеры не должны изменять значение. Так что я бы тоже:

изменения в сеттер

public void setMyValue(String value) {
    if(value == null || value.isEmpty()){
        this.myValue = "N/A";
    } else {
        this.myValue = value;
    }
}

или заставить getter вернуть значение по умолчанию, если значение не установлено правильно:

public String getMyValue() {
    if(this.myvalue == null || this.myvalue.isEmpty()){
        return "N/A";
    }    
    return this.myValue;
}

в случае ленивой загрузки, где я бы сказал, что изменение ваших членов в геттере нормально, вы бы сделали что-то вроде:

public String getMyValue() {
    if (this.myvalue == null) {
        this.myvalue = loadMyValue();
    }    
    return this.myValue;
}

нет. Ты делаешь здесь две вещи. Получение и настройка.

да. это плохая практика.

почему ?

когда значение импортируется в объект (в конструкторе или методе setter), это значение будет проверено, а не проверено, пока не будет вызван метод getter. И, если кто-то будет осторожен, они создадут весь частный метод проверки для этого значения.

private boolean validateThisValue(String a) {
   // return true or false
   // in this example will be
   if(this.myvalue == null || this.myvalue.isEmpty()){
       return false;
   }
   else {
       return true;
   }
}

public void setThisValue(String a) {
    if (validateThisValue(a)) {
        this.myValue = a;
    } 
    else {
        // do something else
        // in this example will be
        this.myValue = "N/A";
    }
}

и в методе геттера никогда не изменяйте состояние значения. Я работал над каким-то проектом, и геттер часто должен быть установлен к const : этот метод не может изменить внутреннее состояние.

по крайней мере, если вы не хотите это усложнять, в методе геттера вы должны возвращение "N / A", а не изменить внутреннее состояние, установите myValue в "N / A".

надеюсь, что это поможет :)

Я думаю, что лучше инициализировать this.myValue = "N/A". И последующие вызовы setMyValue изменить this.myValue согласно вашим условиям бизнеса.
The getMyValue не следует изменять каким-либо образом this.myValue. Если вам нужно вернуть определенное значение, вы должны вернуть это значение (например, "N/A"), а не alter this.myValue . Добытчики не должны изменять значение элемента.

Я обычно определяю конкретный getter.

и не изменять оригинал getter:

 public String getMyValue(){
     return this.myValue
 }

и создать особый getter:

public String getMyValueFormatted(){

    if(this.myvalue == null || this.myvalue.isEmpty()){
       return "N/A";
    }else{
       return this.myValue;
    }
 }

Я бы лучше изменил метод сеттера так, если значение null или пустыми,N/A присваивается атрибуту. Итак, если вы используете атрибут в других методах внутри класса (V. g. toString()) у вас будет Предполагаемое значение.

кроме того, измените метод setter, чтобы запустить исключение, когда заданное значение неправильно, поэтому программист вынужден улучшить его обработку до установки значения.

кроме этого, это ладно.

Я чувствую, что это плохая практика если и пока вы не объясните причину, по которой вам так необходимо изменить объект внутри метода getter вместо того, чтобы делать это внутри метода setter.
Вы чувствуете это не может быть сделано по какой-то причине? Не могли бы Вы уточнить?

делай, что хочешь. В конце концов, геттеры и сеттеры-это просто еще один публичный метод. Вы можете использовать любые другие имена.

но если вы используете фреймворки, такие как Spring, вы обязаны использовать эти стандартные имена, и вы никогда не должны положить ваши пользовательские коды внутри них.

сеттер может изменяться как часть проверки, но геттер должен возвращать значение и позволять проверке выполняться вызывающим. Если ты ... --1-- > do validate, затем как следует документировать.

это на самом деле сильно зависит от контракта, который вы хотите применить с помощью метода get () -. В соответствии с соглашениями о проектировании по контракту вызывающий должен убедиться, что выполнены предварительные условия (что означает, что проверка в методе сеттера часто является фактически плохим дизайном), а вызываемый (я не знаю, является ли это правильным английским термином для этого, т. е. вызываемый) гарантирует, что условия post выполнены.

Если вы определяете свой контракт так, чтобы метод get () - не разрешено изменять объект, то вы нарушаете свой собственный контракт. Подумайте о реализации такого метода, как

public isValid() {
    return (this.myvalue == null || this.myvalue.isEmpty());
}

преимущество этого подхода заключается в том, что вам не нужно проверять, является ли возврат get () "N/A" или что-то еще. Это также можно вызвать перед вызовом set (), чтобы проверить, что вы не вставляете незаконные значения в свой объект.

Если вы хотите установить значение по умолчанию, вы должны сделать это во время инициализации.

абсолютно Да, это плохая практика.

представьте, что вы общаетесь по сети с третьей стороной (remoting, COM,...), это увеличит туда и обратно, а затем ударит производительность приложения.

изменения состояния в геттерах должны быть висячим преступлением. Это означает, что клиентский код должен быть осторожен в отношении порядка, в котором он обращается к геттерам и сеттерам, и для этого он должен знать о реализации. Вы должны иметь возможность вызывать геттеров в любом порядке и получать те же результаты. Связанная проблема возникает, когда сеттер изменяет входящее значение в зависимости от текущего состояния объекта.

для этой цели вы можете использовать некоторый держатель значения. Как необязательный класс в библиотеке guava.