Это хорошая практика программирования? Конструкторы и переменные экземпляра

Question

В Java, было бы плохой практикой программирования делать что-то кроме создания экземпляров переменных вашего экземпляра внутри вашего конструктора?

Я делаю графический интерфейс прямо сейчас, и я думал о кодировании построения GUI внутри конструктора, чтобы в моем главном я мог просто создать новый экземпляр класса для запуска GUI.

Answer 1

Как правило, это хорошая идея, чтобы упаковать вещи в небольшие / краткие и понятные единицы.

В конструкторе происходит инициализация. Если вас беспокоит написание слишком большого количества кода, вы можете упаковать код инициализации пользовательского интерфейса в метод (например, вызвать initUI ()) и вызвать его в конце вашего конструктора

Answer 2

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

Например, если вы создаете класс Window, экземпляр может ожидать, что он также будет иметь Content экземпляр и так далее.Однако этот процесс не ограничивается вещами, на которые вы ссылаетесь, используя переменные экземпляра.

Answer 3

Не забудьте Pattern Builder .Этот шаблон предназначен для того, чтобы вы могли «строить» свои объекты.

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

public class MyJPanelBuilder {
  public JPanel build() {
    JPanel panel = new JPanel();
    // Add all your components to the panel, lay it out how you want etc.
    // You can do it this way because all of the methods required are public!
    return panel;
  }
}

Я предпочитаю этот подход, так как он усложняет нарушение MVC, если вы просто используете виджеты, предоставленные JVM.

Answer 4

Конструктор предназначен для инициализации вашего объекта.Теперь, если при инициализации вашего объекта нужно инициализировать переменные экземпляра и / или вызвать какие-то методы или иметь какую-то логику, которая в порядке - ничего страшного в этом.конструктор.Вместо этого разделите код инициализации на логические порции в отдельных методах и вызовите их из конструктора.Как и в вашем случае,

public class MyClass{
   public MyClass(){
     this.myVar1 = new myVar();
     ...
     buildUI(param1, param2,...);
   }

   //can make it public if you think this method can call to repaint or something
   private void buildUI(Param1 param1, Param2 param2,...){ 
     ....
   }
} 

Answer 5

Как и RAY, я бы посоветовал держать компоненты маленькими и сфокусированными.Чтобы сделать утверждения Нишанта и Маркуса более точными, конструктор должен оставить объект инициализированным, но у вас действительно есть выбор, как это сделать.

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

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

Конечно, в случае зависимостей вам никогда не придется подставлять его, это проще ивсе еще безопасно создавать их экземпляры непосредственно внутри конструктора.Особенно в графических интерфейсах будет много таких случаев (ярлыки и тому подобное).Однако, если у вас есть зависимость извне уровня GUI (например, бизнес-объекта), я бы определенно не создавал ее в конструкторе.