Зачем нам нужен конструктор аргументов default по умолчанию в Java?

Ответ 1

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

Эти структуры используют API отражения и просматривают имена методов, чтобы определить, как устанавливать свойства. Аргументы конструктора могут быть найдены только по типу, а не по имени, поэтому у фреймворка нет способа надежно сопоставить свойства с аргументами конструктора. Следовательно, им требуется конструктор без аргументов для создания объекта, а затем они могут использовать методы установки для инициализации данных.

Некоторые платформы могут поддерживать @ConstructorProperties в качестве альтернативы.

Ответ 2

Я считаю, что фреймворки, требующие конструкторов с нулевым числом public, делают это потому, что они используют отражение для создания типов экземпляров, например. через Class.newInstance().

Что касается того, почему конструктор по умолчанию может не работать для этого случая, здесь соответствующий раздел JLS:

JLS 8.8.9 Конструктор по умолчанию

Если a class не содержит объявлений конструктора, автоматически создается конструктор по умолчанию, который не принимает никаких параметров:

• если class объявлен public, тогда конструктор по умолчанию неявно получает модификатор доступа public;
• если класс объявлен protected, то конструктор по умолчанию неявно получает модификатор доступа protected;
• Если класс объявлен private, то конструктор по умолчанию неявно получает модификатор доступа private;
• В противном случае конструктор по умолчанию имеет доступ по умолчанию, подразумеваемый модификатором доступа.

Итак, в классе public конструктор по умолчанию имеет правильную видимость, но в противном случае должно быть указано явно public.

Ответ 3

Java только предоставляет конструктор no-arg, если другой конструктор не применяется. В ряде Java-API (например, JPA, Serialization и многих других, которые строят объекты из внешнего представления) экземпляр объекта требуется до того, как значения данных объекта могут быть установлены, поскольку определение того, как применяются значения, определенные через экземпляры элементов объекта (например, readExternal (ObjectInput)). Если класс имеет только конструктор, который принимает некоторые аргументы, то может быть невозможно, чтобы библиотека построила экземпляр, если не определен отдельный конструктор no-arg.

Стоит отметить, что это выбор дизайна разработчиком конкретной библиотеки, можно построить API/Framework, который может экрезизировать и воссоздавать объекты, у которых нет конструктора no-arg (определяющего отдельный factory класс - это один подход). Шаблон, требующий конструктора no-arg, появился сначала в Java Serialization (я думаю) и был принят как де-факто стандартный подход к другим библиотекам (например, JPA). Слабостью этого подхода является то, что он предотвращает использование неизменяемых объектов.

Ответ 4

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

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

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

Ответ 5

Две причины: 1), чтобы избежать NullPointerException, если поле данных экземпляра ссылочного типа данных не инициализировано. Предоставление явного конструктора даст вам возможность инициализировать такие поля данных, если они не были инициализированы при объявлении 2) для пользователей, которые хотели бы использовать конструкторы no-arg; они не предоставляются автоматически, если существуют другие конструкторы.

Ответ 6

Многие из этих структур вытекают из более ранних идей " POJO " и особенно JavaBeans. Наименьший полезный Java-объект, по соглашению, должен иметь конструктор без аргументов и каждый член, доступный через методы, такие как get/setProperty1 и is/setProperty1 для логических значений. Если классы следуют этому соглашению интерфейса, инструменты и структуры, использующие отражение, могут работать "из коробки".