Le générateur de modèle vs objet de config
Le générateur de modèle est populaire pour créer des objets immuables, mais il y a un peu de programmation généraux pour créer un générateur de rapports. Donc, je me demande pourquoi ne pas tout simplement à l'aide d'un objet de config.
L'utilisation d'un constructeur devrait ressembler à ceci:
Product p = Product.Builder.name("Vodka").alcohol(0.38).size(0.7).price(17.99).build();Il est évident que c'est très lisible et concis, mais vous avez à mettre en œuvre le constructeur:
public class Product {
public final String name;
public final float alcohol;
public final float size;
public final float price;
private Product(Builder builder) {
this.name = builder.name;
this.alcohol = builder.alcohol;
this.size = builder.size;
this.price = builder.price;
}
public static class Builder {
private String name;
private float alcohol;
private float size;
private float price;
//mandatory
public static Builder name(String name) {
Builder b = new Builder();
b.name = name;
return b;
}
public Builder alcohol(float alcohol) {
this.alcohol = alcohol;
return.this;
}
public Builder size(float size) {
this.size = size;
return.this;
}
public Builder price(float price) {
this.price = price;
return.this;
}
public Product build() {
return new Product(this);
}
}
}Mon idée est de réduire le code à l'aide d'un simple objet de config comme ceci:
class ProductConfig {
public String name;
public float alcohol;
public float size;
public float price;
//name is still mandatory
public ProductConfig(String name) {
this.name = name;
}
}
public class Product {
public final String name;
public final float alcohol;
public final float size;
public final float price;
public Product(ProductConfig config) {
this.name = config.name;
this.alcohol = config.alcohol;
this.size = config.size;
this.price = config.price;
}
}Utilisation:
ProductConfig config = new ProductConfig("Vodka");
config.alcohol = 0.38;
config.size = 0.7;
config.price = 17.99;
Product p = new Product(config);Cette utilisation a besoin d'un peu plus de lignes, mais est également très lisible, mais la mise en œuvre est beaucoup plus simple et peut-être que c'est plus facile à comprendre pour quelqu'un qui n'est pas familier avec le générateur de modèle. En passant: est-il un nom pour ce modèle?
Est-il un inconvénient dans la config de l'approche que j'ai négligé?
- Dans le
Buildervotre setters besoin dereturn this;pour le motif travail. - Merci!!!! Je devrais avoir testé mon code ...
- Avec la config approche objet, vous pouvez aussi faire des choses de type coffre-fort en employant des types fantômes. C'est-à-dire, le compilateur vous permettrait de passer de la configuration de l'instance à l'origine constructeur uniquement lorsque tous les champs nécessaires sont définies. Voir michid.wordpress.com/2008/08/13/...
Vous devez vous connecter pour publier un commentaire.
Le générateur de modèle améliore le découplage - votre Produit peut-être une interface et la seule classe qui sait à propos de la mise en œuvre (ou des implémentations, dans certains cas) est le constructeur. Si le constructeur met également en œuvre une interface alors vous pouvez injecter dans votre code pour augmenter le découplage plus loin.
Ce découplage signifie que votre code est plus facile à gérer et plus facile à tester.
Vous êtes la perte de plusieurs avantages du générateur de modèle, comme cela a déjà été souligné (nouveau est moche et la plus difficile à maintenir et fuite de détails par rapport à un nettoyage du générateur).
Celui qui me manque le plus, cependant, est que le générateur de modèle peut être utilisé pour fournir ce que l'on appelle "fluent interfaces".
Au lieu de cela:
Que vous pouvez faire:
Pas tout le monde comme couramment interfaces, mais ils sont sans aucun doute une très belle utilisation du générateur de pattern (tous couramment l'interface doit utiliser le générateur de modèle, mais pas tous générateur de pattern sont couramment interfaces).
Quelques grands Java collections, comme les Google collections, rend à la fois très libéral et très bonne utilisation de la "fluent interfaces". Je choisirais les présentes toute la journée sur votre "plus facile à type de/moins de caractères" approche : )
Quel problème essayez-vous de résoudre avec votre patron? Le générateur de modèle est utilisé pour les objets avec de nombreux paramètres (facultatif) afin d'éviter des tonnes de différents constructeurs ou très longs. Il garde également votre objet dans un état cohérent (vs javabean modèle) en cours de construction.
La différence entre le constructeur et "objet de config" (se sent comme un bon nom), que vous avez encore de créer l'objet avec le même params par le constructeur ou getter/setter. Cette une) ne marche pas à résoudre le constructeur problème ou b) conserve l'objet de config en état incohérent. Incompatible états de l'objet de config ne soit pas vraiment mal, mais vous pourriez passer un inachevée config objet en tant que paramètre. [Michids lien de types fantômes semblent résoudre ce problème, mais qui, de nouveau, tue la lisibilité (
new Foo<TRUE,TRUE, TRUE, FALSE, TRUE>suce plutôt).] C'est le gros avantage du générateur de motif: vous pouvez valider vos paramètres avant de créer un objet et vous pouvez retourner n'importe quel sous-type (agit comme une usine).Config objets sont valables pour des ensembles de paramètres qui sont tous obligatoires. J'ai vu ce modèle à de nombreuses reprises dans .NET ou java avant.
Avez-vous envisagé d'utiliser générateur-générateur de?
Je pense que le constructeur (avec des préfixes comme "Avec") se lit plus natrually/couramment.
De l'OMI, le générateur de modèle est beaucoup plus roboust si vous avez des choses comme la validation, etc.
Le générateur de modèle dans votre cas peut être changé pour effectuer les opérations suivantes:
La
build()méthode peut tout faire à la validation des trucs qui est nécessaire pour votre générateur.Le générateur de modèle dispose également de la conception de plusieurs advangates (qui peuvent ne pas être applicables dans votre cas). Pour deatils cochez cette question
Product.Je pense personnellement que le générateur de modèle à la première vue, vous offre nettoyeur de code où ces objets sont en fait utilisés. D'autre part, de ne pas avoir des getters/setters ne sera pas très utilisable par un grand nombre de cadres qui attendent chameau cas des getters/setters. C'est une grave tirer en arrière, je sens.
Ce que j'aime aussi avec des getters/setters, c'est que vous voyez clairement ce que vous faites: get ou set. Je ressens avec le constructeur, je suis perdu un peu de clarté intuitive ici.
Je sais que beaucoup de gens ont lu un livre en particulier et que maintenant tout d'un coup, le constructeur modèle a bénéficié de la hype, comme s'il était le nouvel iPhone. Cependant, je ne suis pas un pionnier. Je n'utilise que la "nouvelle manière" lorsqu'il le prouve vraiment un gros gain de temps sur tout le territoire, d'être la performance de l'informatique, de la maintenance, de codage...
Mes mains sur l'expérience, c'est que d'habitude je suis mieux avec des getters/setters et les constructeurs. Il me permet de réutiliser ces POJO est pour n'importe quel but.
Bien que je vois le but de votre Objet de Config, je pense aussi que c'est même plus généraux que par le constructeur, et pour quoi? Quel est le problème avec les poseurs?
Peut-être que nous avons besoin d'inventer un AVEC la clause:
exemple, disons que vous avez
Ah je ne sais pas... je pense que cela peut encore entraîner plus rapide de l'écriture de code, sans la totalité de l'intérieur de la classe de tracas. Croit-on avoir des connexions avec l'Oracle Java gourou?
Il n'a pas l'air aussi propre qu'à l'aide d'un objet avec un constructeur, mais vous enregistrer builder-temps de construction. Et vous pouvez toujours utiliser la classe régulière pojo/bean qui peut être utilisé dans des cadres...
Voulez-vous les gars aiment vraiment, cette clause ou vous pensez qu'il serait plutôt sucer?
Cheers
La configuration du modèle et le générateur de modèle sont fonctionnellement équivalents. Ils ont à la fois résoudre les mêmes problèmes -
Éliminer la nécessité pour les multiples constructeur signatures
Permettre champs uniquement être défini lors de la construction
De permettre aux consommateurs de définir les valeurs qu'ils ont logique par défaut pour les autres valeurs
Tout ce que vous voulez faire dans l'un de ces modèles que vous pouvez faire dans l'autre, comme la seule permettant à l'état d'être ensemble avec des méthodes de validation et de réglage de l'etat encapsulés de la logique. La seule vraie différence est que si vous aimez créer des objets avec la
newterme clé ou si vous le souhaitez appeler un.build()méthode.Le principal inconvénient est qu'il n'est pas dans le livre de Josué, de sorte que les drones ne peut pas envelopper leurs têtes autour de lui.
Vous êtes en utilisant un simple objet de valeur pour contenir plusieurs arguments d'une fonction(/méthode/le constructeur) besoins, il n'y a rien de mal à cela, il a été fait pendant des siècles. Tant que nous n'avons pas nommé de paramètres facultatifs, nous aurons à élaborer des solutions de contournement comme cela - c'est une honte, pas un god damn brillantes inventions des dieux dans le Soleil.
La vraie différence est que vous exposer les champs directement. Joshua n'aurait jamais un public mutable terrain mais il écrit Api qui seront utilisés par des millions de personnes dont la plupart sont des abrutis, et de l'Api doit être sûr d'évoluer dans les décennies à venir, et ils peuvent allouer beaucoup de l'homme des mois juste pour la conception d'une classe simple
Qui sommes-nous pour emmulate que?
Vous ne devez pas utiliser le champ public, mais protégé ou privé. Pour l'accès aux alors vous devriez utiliser les accesseurs et setter pour garder l'encapsulation..