J'essaie de mieux comprendre la pratique générale ... en dérivant spécifiquement cela () dans un constructeur. Je comprends que c'est moins de code, mais je le considère moins lisible. Est-ce que c'est commun / pratique de le faire de cette façon? Ou est-il préférable d'écrire un deuxième constructeur qui le gère spécifiquement? ou toute entrée serait grandement appréciée
7 Réponses :
Je me soucie de moins sur la lisibilité et plus de fiabilité.
Constructeurs enchaînants est beaucoup mieux que les corps de méthode du constructeur de copyposition.
Je suis d'accord enchaînant des constructeurs, c'est mieux que la copie du code. La lisibilité est cependant très importante. Dans ce cas, je pense que des constructeurs enchaînements sont plus lisibles et beaucoup plus fiables. Mais en tant que déclaration générale, "pas soignant" sur la lisibilité est une pratique dangereuse imo.
@foo buggy et lisible ou obscur mais fiable? Bien sûr, ce n'est pas toujours un / ou une situation, mais si vous avez le choix de faire l'un ou l'autre, mieux l'autre. En outre, le code le plus illisible devient plus que compréhensible avec l'application des commentaires du code!
Euh, pourquoi associerez-vous "buggy" avec "lisible"? Que diriez-vous de "lisible et fiable"? Ils ne sont pas mutuellement exclusifs.
@Will Alors parlons-nous de la lisibilité de la vitesse? Ou lorsqu'il est donné le choix entre la lisibilité et la fiabilité pour choisir la fiabilité et le retour avec des commentaires clarifiants?
@Ed n'a jamais réclamé tel, le commentaire directement au-dessus de la vôtre dit qu'il est «pas toujours une / ou une situation». @Brandon qui a dit quelque chose de vitesse? Ai-je mentionné la vitesse? Laissez-moi ctrl-f ... Nope, rien de vitesse. fiabilité> lisibilité , car la lisibilité peut toujours être augmentée avec des commentaires. La fiabilité ne se soucie pas des commentaires de code. Clair, tout le monde?
@Will - C'est bizarre combien de personnes lisent votre réponse et pensaient que vous aviez préconisé un code illisible ou que vous suggérez une lisibilité doit être sacrifiée pour "vitesse". Je m'attendrais à ce que les programmeurs soient moins exposés au grand public à ces types d'inférences, simplement parce que les ordinateurs ne vous laissent pas vous échapper avec ce genre de chose. ("Faites ce que je veux, pas ce que je te dis!")
C'est ainsi que vous faites des constructeurs en chaîne et c'est une chose parfaitement valide à faire.
Il est une bonne pratique d'utiliser Vous devez uniquement "dupliquer" le code lorsque vous en avez besoin, car il doit être différent, il n'y a donc plus de duplicata. De cette façon, avoir un duplicata est un message au lecteur que le code est en réalité différent et qu'il s'agit pour une raison. ceci () dans la mesure du possible. Sinon, vous allez dupliquer du code qui enfreint le principe sec (ne vous répéter pas). Le problème de vous répéter est que chaque fois que vous devez effectuer une modification - même si c'est un simple changement à une seule ligne de code - vous devez N'oubliez pas pour rendre le même Changement de plusieurs endroits et conserver les multiples copies synchronisées.
Bonne réponse et cela clarifie définitivement ma question. Je n'avais pas vu le principe sec et je crois que cela améliorera mon code à travers le conseil. Merci!
Le problème avec les deux constructeurs distincts est qu'ils contiennent souvent du code identique, ce qui peut entraîner des problèmes avec des refactorings ultérieurs, lorsqu'un constructeur est modifié et l'autre non. Vous pouvez donc voir le constructeur enchaînant avec ceci () comme une application du Principe sec .
Les listes d'initialisation sont des pratiques très courantes dans l'industrie.
comme pour la lisibilité ... c'est une question d'opinion. Mais la maintenabilité est généralement un objectif plus élevé de s'efforcer.
Dry est une bonne chose :)
J'aime vraiment le premier moyen (Constructor enchaînant), mais si vous sentez la deuxième façon est plus lisible, allez-y et vous pouvez mettre le code dupliqué que vous avez dans les constructeurs dans une méthode privée pour éviter de casser les personnes de principe sèches ont mentionné.
En outre, j'essaie toujours de coder dans le style du code que je travaille - donc si le style prédominant est l'un ou l'autre, j'irais avec ce style pour la cohérence.
Une autre façon de sécher écrit une méthode d'initialisation, par exemple Cela a tendance à être moins déroutant et plus flexible surtout où il existe de nombreux constructeurs. init (labble, bloop) et tous les constructeurs appelle cette méthode.
Ceci () est un bon moyen d'avoir des propriétés automatiques sur un type de structure et de leur permettre de se mettre dans un constructeur paramétré. Sans lececi () , cela nécessite que vous utilise des champs de support explicite.@Dan: C'est brillant, je n'y ai jamais pensé! À l'avenir, je vais utiliser
ceci () dans les structures qui ont des propriétés automatiques! Merci!