Оборонительная копия: следует ли указывать в Javadoc?

Question

Насколько я понимаю, геттеры/сеттеры всегда должны делать копии, чтобы защитить данные.

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

b = a.getB(); 
b.setC(someValue); 

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

b = a.getB(); 
b.setC(someValue); 
a.setB(b); 

Спасибо заранее S

Answer 1

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

Сказав все это, вышесказанное, безусловно, не является обычной практикой и часто прагматичным выбором.

Когда вы подвергаете объект через Get(), у вас есть три варианта:

1. открывающих реальный объект
2. сделать защитную копию
3. выставить объект, который оборачивает оригинал, но запрещает модификацию , например вы можете обернуть исходный объект в ограниченном интерфейсе. См. (Например) Collections.unmodifiableCollection(), который обертывает исходную коллекцию (и не копирует ее), но предоставляет интерфейс, который не позволяет изменять.

Независимо от того, что вы делаете, вы должны документировать его в интерфейсе (и, следовательно, в Javadoc). В противном случае вы можете изменить его позже, и зависимый код может легко сломаться.

Answer 2

Ну, setC нарушает Law of Demeter, поэтому я не думаю, что назвал бы это лучшей практикой. («Закон» немного силен - например, он, как правило, не применяется к плавным интерфейсам.)

Это означает, что геттеры должны не всегда делают копии ИМХО. Выполнение глубокого клона может быть дорогостоящим. Существуют и другие варианты, такие как неизменяемые объекты.

И, в сущности, существуют прагматические соображения.

Но я ошибался на стороне TMI (слишком много информации) в JavaDoc.

Answer 3

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

Таким образом, если вы доверяете коду клиента, не беспокойтесь об этом.

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

И если есть проблема, кто все равно читает JavaDoc и т.п.? Кто-нибудь там?

Answer 4

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

Обычно я придерживаюсь такого подхода, если я пишу API, который я, вероятно, буду использовать самостоятельно или внутри своей команды разработчиков; то есть где я знаю, что «клиенты» будут хорошими гражданами!

// Immutable interface definition. 
public interface Record { 
    String getContent(); 
} 

// Mutable implementation of Record interface. 
public class MutableRecord implements Record { 
    private final String content; 

    public MutableRecord(String content) { 
    this.content = content; 
    } 

    public String getContent() { 
    return content; 
    } 

    public void setContent(String content) { 
    this.content = content; 
    } 
} 

// API that only exposes the object via its Record interface. 
public class MyApi { 
    private final MutableRecord mutableRecord; 

    public Record getRecord() { 
    return mutableRecord; 
    } 
}