Combien d'arguments du constructeur est de trop?

Disons que vous avez une classe appelée Client, qui contient les champs suivants:

Nom d'utilisateur
E-mail
Prénom
Nom De Famille

Disons aussi que, selon une logique d'entreprise, tous les objets de Client doit avoir ces quatre propriétés définies.

Maintenant, on peut le faire assez facilement en obligeant le constructeur à préciser chacun de ces propriétés. Mais il est assez facile de voir comment cela peut devenir une spirale hors de contrôle lorsque vous êtes forcé d'ajouter plus de champs nécessaires à l'objet Client.

J'ai vu des classes qui prennent en 20+ arguments en leur constructeur et c'est juste une douleur à utiliser. Mais, sinon, si vous n'avez pas besoin de ces champs, vous courez le risque d'avoir pas défini d'informations, ou pour le pire, le référencement d'un objet erreurs si vous comptez sur le code appelant à spécifier ces propriétés.

Existe-il des alternatives à cette ou pensez-vous que vous avez juste à décider si X montant des arguments du constructeur, c'est trop pour vous de vivre?

InformationsquelleAutor Kevin Pang | 2008-09-02

110

Deux approches de conception à considérer

La essence modèle

La interface fluide modèle

Ce sont à la fois semblables dans leur intention, en qui nous avons lentement construire un objet intermédiaire, et ensuite créer notre objet cible en une seule étape.

Un exemple de l'interface fluide dans l'action serait:
```
public class CustomerBuilder {
String surname;
String firstName;
String ssn;
public static CustomerBuilder customer() {
return new CustomerBuilder();
}
public CustomerBuilder withSurname(String surname) {
this.surname = surname; 
return this; 
}
public CustomerBuilder withFirstName(String firstName) {
this.firstName = firstName;
return this; 
}
public CustomerBuilder withSsn(String ssn) {
this.ssn = ssn; 
return this; 
}
//client doesn't get to instantiate Customer directly
public Customer build() {
return new Customer(this);            
}
}
public class Customer {
private final String firstName;
private final String surname;
private final String ssn;
Customer(CustomerBuilder builder) {
if (builder.firstName == null) throw new NullPointerException("firstName");
if (builder.surname == null) throw new NullPointerException("surname");
if (builder.ssn == null) throw new NullPointerException("ssn");
this.firstName = builder.firstName;
this.surname = builder.surname;
this.ssn = builder.ssn;
}
public String getFirstName() { return firstName;  }
public String getSurname() { return surname; }
public String getSsn() { return ssn; }    
}
```
```
import static com.acme.CustomerBuilder.customer;
public class Client {
public void doSomething() {
Customer customer = customer()
.withSurname("Smith")
.withFirstName("Fred")
.withSsn("123XS1")
.build();
}
}
```
- Je sais ce que le "Paramètre Nommé Idiome": parashift.com/c++-faq-lite/ctors.html#faq-10.18. Liés: Il est aussi "le nom du Constructeur de l'Idiome": parashift.com/c++-faq-lite/ctors.html#faq-10.8
- peut-on séparer l'appelant et appelé les segments de code pour le rendre plus clair ce sont des entités distinctes?
- Le chèque pour les valeurs null (nom == null || firstName == null || ssn == null) doit être effectuée SUR L'objet Client. C'est en raison de la possibilité de ces valeurs en cours de modification avant de l'objet Client est créé. En outre, assurez-vous que les champs de la classe de la Clientèle sont tous déclarés à être "privé de la finale de la" prise de la Clientèle immuable.
- vos liens semblent être mauvais maintenant, "Paramètre Nommé Idiome" est maintenant au parashift.com/c++-faq-lite/named-parameter-idiom.html "le nom du Constructeur de l'Idiome" est maintenant ici: parashift.com/c++-faq-lite/named-ctor-idiom.html
- J'aime la fluidité de code client, mais je n'aime pas la répétition des variables d'instance dans CustomerBuilder et Customer. En outre, cet exemple est très bien si toutes les variables d'instance sont facultatives, mais si tous sont obligatoires et vous avez des dizaines d'entre eux, alors je ne suis pas sûr que vous serez en mesure d'éviter constructeur avec tous ces arguments. Si vous n'avez pas un constructeur avec tous ces attributs obligatoires puis-je, en tant que client codeur, ne serait pas en mesure de voir que par l'interface d'une classe je suis sur le point de créer et c'est quelque chose que je ne voudrais pas.
- N'est-ce pas CustomerBuilder plus comme un DTO?
- Je vous suggère de ne PAS jeter de NullPointException lors de la vérification si un argument est null. Ce n'est pas ce que les NPE est pour. Mieux jeter une IllegalArgumentException ("Levée pour indiquer qu'une méthode a été adoptée illégale ou inappropriée de l'argument." voir docs.oracle.com/javase/7/docs/api/java/lang/...)
- Bien que ces modèles sont précieux, ils ne répondent pas à la question "Combien d'arguments du constructeur, c'est trop". Aussi, Kamil est correct: Qui ressemble à un DTO et pas le générateur de modèle. Le générateur de modèle a généralement une méthode appelée .build() qui va fournir à l'instance. À mon humble avis, les constructeurs donner un peu plus de marge de manœuvre sur le nombre de paramètres qu'ils peuvent prendre. D'autre part, je trouve les méthodes d'instance devrait être plus stricte en ce sens, 0-3 devrait être une bonne règle de base. En tout cas, quelque chose de plus que de 7 sonne comme une odeur de code.
- Vous avez une faute de frappe à la fin doit être CustomerBuilder pas le Client le client de la méthode de classe doSomething.
- non, il n'y a pas de faute de frappe
- ohh désolé je me suis trompé de ne pas voir la méthode statique de la clientèle et sur le premier regard, elle ressemblait à une classe de la Clientèle. De toute façon je upvote sur le commentaire précédent vraiment de bonne réponse.
InformationsquelleAutor toolkit
29

Je vois que certaines personnes recommandent de sept comme une limite supérieure. Apparemment, il n'est pas vrai que les gens peuvent tenir sept choses dans leur tête à la fois; ils ne peuvent se rappeler de quatre (Susan Weinschenk, 100 Choses à Chaque Concepteur a Besoin de Savoir sur Personnes, 48). De même, je considère que quatre à être quelque chose d'une grande orbite autour de la terre. Mais c'est parce que ma pensée a été modifié par Bob Martin.

Dans Propre Code, Oncle Bob plaide pour trois comme supérieur général de limite pour le nombre de paramètres. Il fait de la radicalité de la demande (40):

Le nombre idéal d'arguments pour une fonction est égale à zéro (niladiques). Vient ensuite un (monadique), suivie de près par deux (dyadique). Trois arguments (triadique) doit être évitée autant que possible. Plus de trois (polyadic) nécessite très spécial justification—et puis, ne doit pas être utilisé de toute façon.

Il dit cela à cause de la lisibilité, mais aussi du fait de la testabilité:

Imaginer la difficulté de l'écriture des cas de tests pour s'assurer que toutes les différentes combinaisons d'arguments fonctionner correctement.

Je vous encourage à trouver un exemplaire de son livre et à la lecture de sa pleine discussion des arguments de la fonction (40-43).

Je suis d'accord avec ceux qui ont mentionné le Principe de Responsabilité Unique. Il est difficile pour moi de croire qu'une classe qui a besoin de plus que deux ou trois valeurs/des objets sans valeurs par défaut raisonnables a vraiment qu'une seule responsabilité, et ne serait pas mieux avec une autre classe extrait.

Maintenant, si vous êtes l'injection de vos dépendances par le constructeur, Bob Martin arguments au sujet de combien il est facile d'invoquer le constructeur ne pas tellement s'appliquent (parce que d'habitude, alors il existe un seul point dans votre application où vous fil, ou vous avez même un cadre qui le fait pour vous). Toutefois, le Principe de Responsabilité Unique est toujours d'actualité: une fois qu'une classe a quatre dépendances, je considère que l'odeur qu'elle est en train de faire une grande quantité de travail.

Cependant, comme avec toutes les choses dans l'informatique, il y a sans doute valides pour avoir un grand nombre de paramètres du constructeur. Ne pas déformer votre code afin d'éviter à l'aide d'un grand nombre de paramètres, mais si vous utilisez un grand nombre de paramètres, d'arrêter et de lui donner une certaine pensée, car il peut signifier que votre code est déjà tordu.
- Je n'ai jamais passer des arguments des constructeurs... j'ai tous les passer dans une fonction init, et l'argument est 1 objet contenant tous les arguments requis. Mais alors, je ne javascript... qu'est-Ce que Java?
- je me suis toujours demandé, comment cela se joue avec des "classes de données", qui existent juste pour tenir les données connexes. Si vous appliquez cela à l'OP de la question de sa classe est seulement de rétention de données pour un client. Toute réflexion sur la façon dont les paramètres pourrait être réduit dans ce cas?
- Il y a aussi une critique semblable où un constructeur peut prendre seulement 3 arguments, mais l'ensemble de ces arguments sont de grandes classes de composés. Donc, en substance, vous êtes l'envoi de 60 paramètres du constructeur, c'est juste qu'ils sont emballés.
- BTW, après avoir pris un programmeur fonctionnel je ne suis pas le disciple de l'Oncle Bob que j'étais. Je ne suis pas entièrement d'accord avec cette réponse plus.
- Je ne suis qu'un couple de chapitres dans un Code Propre, mais lors de la lecture sur Monadique, en Dyade et la triade des fonctions, je me demandais si les constructeurs étaient une exception ou pas. Je ne me souviens pas clairement de faire une distinction. Je vois dans une tentative pour éviter Dyadique/Triade des fonctions(ou des) une classe peut être faite pour envelopper les arguments. Mais, à ce point lors de la création de la classe wrapper, l'auteur ne semble pas donner une meilleure pratique sur la façon de définir les propriétés de la classe wrapper.
InformationsquelleAutor Keith Pinson

Dans votre cas, s'en tenir avec le constructeur. L'information appartient à la Clientèle et les 4 champs sont beaux.

Dans le cas où vous avez de nombreux champs obligatoires et facultatifs le constructeur n'est pas la meilleure solution. Comme @boojiboy dit, c'est difficile à lire et il est aussi difficile d'écrire du code client.

@contagieuse a suggéré d'utiliser le modèle par défaut et les setters pour facultatif des attributs. Que les mandats que les champs sont mutables, mais c'est un problème mineur.

Joshua Bloc sur l'efficacité de Java 2-dire que, dans ce cas, vous devriez envisager un constructeur. Un exemple tiré du livre:

 public class NutritionFacts {  
private final int servingSize;  
private final int servings;  
private final int calories;  
private final int fat;  
private final int sodium;  
private final int carbohydrate;  
public static class Builder {  
//required parameters  
private final int servingSize;  
private final int servings;  
//optional parameters  
private int calories         = 0;  
private int fat              = 0;  
private int carbohydrate     = 0;  
private int sodium           = 0;  
public Builder(int servingSize, int servings) {  
this.servingSize = servingSize;  
this.servings = servings;  
}  
public Builder calories(int val)  
{ calories = val;       return this; }  
public Builder fat(int val)  
{ fat = val;            return this; }  
public Builder carbohydrate(int val)  
{ carbohydrate = val;   return this; }  
public Builder sodium(int val)  
{ sodium = val;         return this; }  
public NutritionFacts build() {  
return new NutritionFacts(this);  
}  
}  
private NutritionFacts(Builder builder) {  
servingSize       = builder.servingSize;  
servings          = builder.servings;  
calories          = builder.calories;  
fat               = builder.fat;  
soduim            = builder.sodium;  
carbohydrate      = builder.carbohydrate;  
}  
}

Et ensuite l'utiliser comme ceci:

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
calories(100).sodium(35).carbohydrate(27).build();

L'exemple ci-dessus a été prise à partir de Efficace Java 2

Et qui ne fait pas que s'applique à un constructeur. Citant Kent Beck dans La Mise En Œuvre Des Schémas:

setOuterBounds(x, y, width, height);
setInnerBounds(x + 2, y + 2, width - 4, height - 4);

Le rectangle explicite comme un objet, explique le code mieux:

setOuterBounds(bounds);
setInnerBounds(bounds.expand(-2));

Bien sûr, si tous les arguments sont Requis dans le constructeur, tu viens de finir le déplacement d'un grand constructeur d'un endroit à un autre.
Je sais que cela a été écrit il y a quelques temps, mais je n'aime pas cette solution. Maintenant, avec des paramètres Nommés, est-ce toujours considéré comme une bonne pratique?

InformationsquelleAutor Marcio Aguiar

5

Je pense que le "pur OOP", la réponse est que si les opérations de la classe ne sont pas valides lorsque certains membres ne sont pas initialisé, alors ces membres doit être défini par le constructeur. Il y a toujours les cas où les valeurs par défaut peuvent être utilisés, mais je vais supposer que nous n'êtes pas tenu de cette affaire. C'est une bonne approche lorsque l'API est fixe, car la seule admissible constructeur après l'API va public va être un cauchemar pour vous et tous les utilisateurs de votre code.

En C#, ce que je comprends sur les lignes directrices de conception, c'est que ce n'est pas nécessairement la seule façon de gérer la situation. En particulier avec des objets WPF, vous trouverez que .NET les classes ont tendance à favoriser sans paramètre constructeurs et lève des exceptions si les données n'ont pas été initialisé à un état souhaité avant d'appeler la méthode. C'est probablement surtout spécifiques à la composante de base de la conception de bien; je ne peux pas venir avec un exemple concret d'une .NET de classe qui se comporte de cette manière. Dans votre cas, ce serait certainement causer une augmentation de la charge sur des tests pour s'assurer que la classe n'est jamais enregistré à la banque de données, à moins que les propriétés ont été validées. Honnêtement, de ce fait, je préfère le "constructeur définit les propriétés nécessaires à l'approche du" si votre API est définie dans la pierre ou pas public.

La seule chose que je suis certain, c'est qu'il y a probablement d'innombrables méthodes pour résoudre ce problème, et chacun d'eux présente son propre ensemble de problèmes. La meilleure chose à faire est d'apprendre autant de modèles que possible et de choisir le meilleur pour le job. (N'est-ce pas un tel cop-out d'une réponse?)

InformationsquelleAutor OwenP
5

Je pense que votre question est plus sur la conception de vos classes que sur le nombre d'arguments dans le constructeur. Si j'ai besoin de 20 morceaux de données (arguments) pour réussir à initialiser un objet, je serais probablement envisager de diviser la classe.
- Parfois, il n'est tout simplement pas possible. Envisager un fichier Excel avec 50 colonnes qui doivent être traitées. L'idée de MyExcelFileLine classe a un constructeur avec 50 arguments est assez effrayant.
InformationsquelleAutor vitule
4

Steve Mcconnell écrit dans le Code Complet que les gens ont du mal à tenir plus de 7 choses dans leur tête à un moment, alors que j'avais le numéro, j'ai essayer de rester sous.
- Mais voir Weinschenk, 100 Choses à Chaque Concepteur a Besoin de Savoir sur Personnes, 48. Apparemment, cela a été démenti: quatre est un plus exacte de la limite supérieure.
- hmmm voyons voir, 3.1415926....ouais, il est d'environ 7 je dirais.
InformationsquelleAutor Booji Boy
3

Si vous avez unpalatably de nombreux arguments, puis il suffit de les emballer ensemble dans les structures /POD classes, de préférence déclaré que les classes intérieures de la classe en cours de construction. De cette façon, vous pouvez toujours exiger les champs, tout en rendant le code qui appelle le constructeur raisonnablement lisible.

InformationsquelleAutor McKenzieG1
3

Je pense que tout dépend de la situation. Pour quelque chose comme votre exemple, une classe de clients, je ne voudrais pas courir le risque d'avoir que des données étant pas défini en cas de besoin. Sur le revers de la médaille, le passage d'une structure permettrait d'effacer la liste des arguments, mais vous auriez encore beaucoup de choses à définir dans la structure.

InformationsquelleAutor Ethan Gunderson
3

Je pense que le plus simple serait de trouver un acceptable par défaut pour chaque valeur. Dans ce cas, chaque champ dirait qu'il serait requis pour la construction, peut-être que la surcharge de l'appel de la fonction, de sorte que si quelque chose n'est pas défini dans l'appel, pour le mettre en défaut.

Ensuite, de lecture et de définition des fonctions pour chaque propriété de sorte que les valeurs par défaut peut être modifié.

Java mise en œuvre:
```
public static void setEmail(String newEmail){
this.email = newEmail;
}
public static String getEmail(){
return this.email;
}
```
C'est aussi une bonne pratique de garder vos variables globales sécurisé.

InformationsquelleAutor helloandre
2

Style compte pour beaucoup, et il me semble que si il ya un constructeur avec 20+ arguments, la conception doit être modifiée. Fournir des valeurs par défaut raisonnables.

InformationsquelleAutor Adam Hollidge
1

Je suis d'accord sur l'article 7 de la limite Boojiboy mentionne. Au-delà, il peut être intéressant de regarder anonyme (ou spécialisé) types, IDictionary, ou d'indirection via clé primaire d'une autre source de données.

InformationsquelleAutor spoulson
1

J'avais encapsuler dans des domaines similaires dans un objet de sa propre sa propre construction/validation de la logique.

Dire par exemple, si vous avez des
- BusinessPhone
- BusinessAddress
- HomePhone
- HomeAddress
Je voudrais faire une classe qui stocke le téléphone et l'adresse avec une étiquette précisant que sa "maison" ou une "entreprise" téléphone/adresse. Et puis de réduire les 4 champs de simplement un tableau.
```
ContactInfo cinfos = new ContactInfo[] {
new ContactInfo("home", "+123456789", "123 ABC Avenue"),
new ContactInfo("biz", "+987654321", "789 ZYX Avenue")
};
Customer c = new Customer("john", "doe", cinfos);
```
Qui devrait en faire regarder moins comme des spaghettis.

Sûrement, si vous avez beaucoup de domaines, il doit y avoir un modèle, vous pouvez extraire cela ferait une belle unité de la fonction qui lui est propre. Et rendre plus lisible le code aussi.

Et la suivante est aussi des solutions possibles:
- Étaler la logique de validation au lieu de les stocker dans une unique classe. Valider la saisie de l'utilisateur et, puis valider à nouveau à la couche de base de données etc...
- Faire un CustomerFactory classe qui m'aiderait à construire Customers
- @marcio la solution est également intéressante...
InformationsquelleAutor chakrit
0

Suffit d'utiliser des arguments par défaut. Dans une langue qui prend en charge la méthode par défaut arguments (PHP, par exemple), on pourrait faire ça dans la signature de la méthode:

public function doSomethingWith($this = val1, $this = val2, $this = val3)

Il y a d'autres façons de créer des valeurs par défaut, comme dans les langages qui prennent en charge la surcharge de méthode.

Bien sûr, vous pouvez également définir des valeurs par défaut lorsque vous déclarez les champs, si vous le jugez approprié de le faire.

- Il vraiment tout se résume à savoir si ou non il est approprié pour vous de définir ces valeurs par défaut, ou si des objets specced à la construction de tous les temps. C'est vraiment une décision que vous seul pouvez faire.

InformationsquelleAutor Brian Warshaw
-1

À moins qu'il y a plus de 1 argument, j'ai toujours utiliser des tableaux ou des objets comme paramètres du constructeur et de compter sur l'erreur de vérification pour vous assurer que les paramètres requis sont là.
- C'est un horroble idée parce que dans ce cas, vous haver pas de compilateur vérifie incorrect d'arguments, pas de typehints, ...
InformationsquelleAutor Aldie

Vous devez vous connecter pour publier un commentaire.