Почему бы не использовать атрибут напрямую, а использовать метод getXXX ()

Question

В методе некоторых доменных объектов они не использовали атрибут напрямую, а использовали метод get.Зачем ?Один пример следующим образом:

private List<String> errorCodeList = new ArrayList<String>();  

/** 
 * Add all errors to the error list.
 */
public void addAllErrors(Collection<String> theErrorStrings) {
    if (errorCodeList == null) {
        errorCodeList = new ArrayList<String>();
    }

    for (String aString: theErrorStrings) {
        getErrorCodeList().add(aString);
    }
}


/**
 * @return the errorCodes
 */
public List<String> getErrorCodeList() {
    return errorCodeList;
}
/**
 * Set the error strings.
  */
public void setErrorCodeList(List<String> allErrors) {
    this.errorCodeList = allErrors;
}

Answer 1

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

public void addAllErrors(Collection<String> theErrorStrings) {
    for (String aString: theErrorStrings) {
        getErrorCodeList().add(aString);
    }
}

public List<String> getErrorCodeList() {
    // TODO synchronization?
    if (errorCodeList == null) {
        errorCodeList = new ArrayList<String>();
    }

    return errorCodeList;
}

Answer 2

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

Очевидно, есть исключения, когда вам нужно получить доступ к полю через геттер:

• Когда он лениво создан.
• Когда получатель вычисляет значение на лету.

Answer 3

Это вопрос инкапсуляции.Предоставляя доступ к переменным экземпляра только через методы получения и установки, вы скрываете внутреннее представление.Таким образом, вы можете впоследствии изменить реализацию без изменения интерфейса.Вы можете решить, что было бы удобнее использовать HashMap для хранения кодов ошибок (по любой причине), и как только вы изменили это, весь доступ к полю нарушился.Однако если вы предоставили метод получения и установки, вы можете сохранить их, как они есть, несмотря на измененное внутреннее представление.

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

Answer 4

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

Answer 5

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

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

Конечно, есть компромисс с дополнительным вызовом метода (если компилятор не достаточно умен, чтобы выполнить преобразование).1006 * Тем не менее, я согласен с Адамски, я тоже не фанат этого.

Answer 6

Это инкапсуляция:

Инкапсуляция может быть описана как защитный барьер, который предотвращает код и данные, случайно выбранные другим кодом, определенным вне класса. Доступ к данным и коду строго контролируется по интерфейсу.

Более подробная информация доступна здесь .