Недавно я увидел этот конструктор в классе:
public MyClass(){ }
Других конструкторов не было.
Есть ли причина для этого? Java автоматически создает конструктор по умолчанию, поэтому почему вы объявите его явно? Или это считается хорошей практикой так же, как использование фигурных скобок для операторов с одним оператором if - в случае добавления других конструкторов позже, и вы забываете, что у вас нет значения по умолчанию...?
Несколько второстепенных моментов, которые вряд ли могут быть причиной того, что вы видели это в этом случае.
Что касается "в случае добавления других конструкторов позже, и вы забываете, что у вас нет значения по умолчанию", это может быть причиной, я полагаю. Но если бы был добавлен конструктор не по умолчанию, любой код, который использовал конструктор по умолчанию, не смог бы скомпилироваться, так что парню, добавившему новый constrcutor, как правило, нужно было бы также добавить исправление для по умолчанию ctor.
И снова я не могу придумать какого-либо особого вреда в том, чтобы определить пустой пул (хотя теперь, когда я набрал это, у меня возникает ощущение, что кто-то может указать на какой-то угол С++, где он может вас укусить).
Он не играет никакой роли и может быть безопасно удален.
Вот что говорит Java Language Specification:
Если класс не содержит конструктора объявления, затем по умолчанию конструктор, который не принимает параметров автоматически предоставляется:
- Если объявляемый класс является искомым классом Object, тогда Конструктор по умолчанию имеет пустое тело.
- В противном случае конструктор по умолчанию не принимает никаких параметров и просто вызывает конструктор суперкласса без Аргументы.
Таким образом, конструктор по умолчанию будет создан. Нет смысла писать, если вы этого не сделаете. должен.
IMO вы должны делать это только в том случае, если хотите изменить уровень видимости своего конструктора, т.е. сделать его конфиденциальным или защищенным пакетом.
Хотя ничего не получается, добавив конструктор явно на технический уровень, есть потенциальные причины для этого. Можно было бы, если бы класс был создан с помощью отражения, вы можете захотеть поместить некоторую документацию по конструктору по умолчанию, указав, что это требуется, даже если добавление нового конструктора не вызовет ошибки компиляции.
Другим является то, что некоторые стандарты кодирования предпочитают его, чтобы явно указать, что вы думали о том, какой конструктор должен использовать этот класс.
Потому что вы верите во второе предложение zen python:
Явный лучше, чем неявный.
Исправьте меня, если я ошибаюсь (я не делал Java некоторое время), но разве это не предотвращает вызов родительского конструктора? В этом случае аргументация, очевидно, заключается в том, что родитель будет делать что-то автоматически, что вы не хотите в этом классе.
Мне учили, что конструктор стандартных значений по умолчанию был специфицирован java bean. Страница wikipedia http://en.wikipedia.org/wiki/Java_Bean также перечисляет его как требование.
С другой стороны, я посмотрел на сайт Sun/Oracle и не мог найти упоминания об этом. См. http://java.sun.com/developer/onlineTraining/Beans/Beans1/simple-definition.html
На самом деле есть веская причина включить его в упомянутые ответы:
Если существование конструктора без аргумента явно является частью контракта для вашего объекта, то оно должно быть явно указано.
Если вы явно намерены для клиента подклассифицировать ваш код, как, например, Java Swing, то это хорошая идея явно создать доступный конструктор no-arg, даже если нет других конструкторов. В противном случае, если другой программист в своей мудрости решает сделать другой конструктор, новый явный конструктор удалит неявный конструктор no-arg и сломает клиентский код.
Если код подклассифицирован в вашей собственной базе кода, тогда это будет отображаться как ошибка компилятора, но если ваш код будет опубликован как jar и подклассифицирован клиентом, ошибки компилятора не будет.
Конечно, вы можете утверждать, что если в его части вашего контракта у вас должен быть тест для юнита, и вы были бы правы! Но если вы работаете с большой базой кода, где тесты занимают часы для ежедневной сборки, ломая вашу ежедневную сборку, потому что вы забыли, что вам пришлось явно создавать конструктор без аргумента, когда добавление конструктора является огромным временем, когда явный конструктор и комментарий мог бы избежать каких-либо ошибок.
Цель хорошего кода - сделать его как можно проще для другого разработчика, чтобы изменить его без ошибок!