Блог

В некотором методе объекта домена они не использовали атрибут напрямую, а использовали метод 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;
}
 

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

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

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

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

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

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

 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;
}
 

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

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

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

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

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

Конечно, есть компромисс с дополнительным вызовом метода (если только компилятор не достаточно умен, чтобы выполнить преобразование).

Тем не менее, я согласен с Адамски, я тоже не фанат этого.

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