web-dev-qa-db-fra.com

Écrire explicitement constructeur vide par défaut

Est-il logique d'écrire un constructeur par défaut lorsqu'il n'a aucun argument, corps vide et aucun autre constructeur n'existe?

Le seul avantage que je puisse penser, c'est réduire le risque d'oublier d'ajouter le constructeur par défaut lorsqu'il est créé. Mais cette erreur apparaîtrait de toute façon si le constructeur par défaut est réellement utilisé (au moins si la classe est "interne" et non dans une bibliothèque), et si elle n'est pas utilisée, elle peut être omise (yagni).

Quel avantage cela peut-il avoir?

6
superM

Il n'y a pas d'avantage sauf Vous interagissez avec un outil ou un cadre qui détecte les méthodes et constructeurs déclarés de votre classe via une réflexion, puis des choses différentes selon lesquelles il trouve le constructeur par défaut ou non. (Je semble me rappeler que les premières versions du printemps ou de l'hibernate ont fait cela.)

Sinon, comme vous le dites, toute incohérence serait marquée par le compilateur, il est donc notamment de déclarer des choses qui seraient automatiquement générées de toute façon.

7
Kilian Foth

Le seul avantage que je puisse prévoir, c'est que vous pouvez ajouter une documentation spécifique à ce constructeur, par exemple pour décrire comment traiter l'objet après l'instanciation, etc.

Dans aucun autre cas, je ne pense pas que ce soit utile.

4
Jérôme

Mais cette erreur apparaîtrait de toute façon si le constructeur par défaut est réellement utilisé (au moins dans la classe est "interne" et non dans une bibliothèque), et s'il n'est pas utilisé, il peut être omis (Yagni).

Déserialisation XML. Oui, l'erreur apparaîtrait, mais assez tard - comme une exception à l'exécution.

4
Konrad Morawski