Всегда ли проблема выхода объекта из конструктора в Java?

Question

По соображениям безопасности потоков это аргументировано:

Не разрешать использование этой ссылки во время строительства.

Но всегда ли это проблема, и она должна бытьизбегать с помощью newInstance() методов?Внутри моего модельного класса у меня есть TableModel, экземпляр которого должен быть создан внутри класса модели, но для которого также требуется ссылка на класс модели:

public class MainModel {

   TableModel tableMode;

   public MainModel() {
      tableModel = new MyTableModel(this);
   }
}

Если конструктор не использует это сразу, то это тогдабезопасно или его следует избегать каким-либо образом?

Answer 1

Если в MyTableModel ничего не будет сделано в других потоках и т. Д. - или скопировать переменную в некоторые другие общие данные, такие как статическая переменная, - тогда это безопасно.

Конечно, еслиMyTableModel начинает вызывать методы для ссылки MainModel в своем конструкторе, затем он будет вызывать их для объекта, который еще не полностью инициализирован, что может вызвать проблемы, но на самом деле это не связано с потоками.

Я немного больше писал об этом некоторое время назад.

Answer 2

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

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

Я думаю,лучше спросить, почему MyTableModel нужно видеть экземпляр MainModel?Часто двунаправленная видимость является признаком некоторого вредного сцепления.

Answer 3

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

например. Я помню один класс с именем c, который был написан целиком в одну строку для экономии места (без разрывов строки) и использовал только односимвольные переменные / поля и имел один-два символьных метода. Это не было намеренно запутано, разработчик думал, что это было наиболее эффективным. Класс работал нормально до тех пор, пока вам не нужно было понимать, как его изменить.