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

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

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

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

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

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

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

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

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

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

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

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