Доступ частного поля другого объекта в конструкторах копии - Действительно проблема?
В моем JAVA-приложении у меня есть некоторые конструкторы копии как это
public MyClass(MyClass src) {
this.field1 = src.field1;
this.field2 = src.field2;
this.field3 = src.field3;
...
}
Теперь Netbeans 6.9 предупреждает об этом и интересно что не так с этим кодом?
Мои проблемы:
- Используя методы считывания мог бы представить нежелательные побочные эффекты. Новый объект больше нельзя было бы считать копией оригинала.
- Если бы это рекомендуется с помощью методов считывания, разве это не было бы более последовательно, если можно было бы использовать методы set для нового экземпляра также?
Править: Фактическое предупреждение является "Доступом частного поля другого объекта" и единственного доступного действия, которое предлагает Netbeans, добавляет a @SuppressWarnings("AccessingNonPublicFieldOfAnotherObject")
Мой код на самом деле так же тривиален как данный пример.
4 ответа
Я не вижу проблем с кодом. На самом деле, я разделяю ваши опасения и предпочел бы не использовать геттеры.
Какое именно предупреждение вы получаете? Может быть, оно связано с чем-то, что вы нам не показываете?
Обновление: Похоже, Netbeans действительно жалуется именно на это. Это довольно спорное предупреждение для поставки с IDE, я бы подумал.
Я не знаю, почему NetBeans предупреждает, но вы фактически делаете неглубокую копию. Ваша копия разделяет field1, field2 и field3 с src, и поэтому модификация field3, скажем, List, будет отражена в оригинале.
private List field1;
public MyClass(MyClass src) {
this.field1 = src.field1;
this.field2 = src.field2;
this.field3 = src.field3;
field1.add(new Object()); // field1 of src also modified
...
}
Это напоминает мне обсуждение ADT против объекта .
ADT может получить доступ к внутреннему состоянию другого экземпляра ADT. Философия объекта предотвратила бы это и обеспечила бы доступ через геттер / сеттер, чтобы гарантировать независимость представления .
Это был осознанный выбор, чтобы переменные экземпляров в Java были частными , а не частными объектами (в последнем случае используется только this.privateInstVar разрешено, но не obj.privateInstVar ).
В этом есть как сильные, так и слабые стороны. Это особенно удобно, когда дело касается клонирования и равенства . С другой стороны, его можно неправильно использовать и нарушить инкапсуляцию .
Это почти философский спор. Но ИМХО то, что ты делаешь, нормально.
Возможно, класс мог бы предоставить метод неглубокого копирования, который знает, какие данные нужно вернуть в скопированный объект. При необходимости можно было бы обеспечить и глубокое копирование.
public MyClass shallowCopy() {
MyClass aCopy = new MyClass();
aCopy.field1 = this.field1;
aCopy.field2 = this.field2;
aCopy.field3 = this.field3;
}