Le modèle d'usine doit-il contenir une logique de validation ?

Question

Lorsque l'on utilise le modèle de la fabrique, celle-ci doit-elle contenir une logique de validation ou faut-il laisser les classes appelantes s'occuper de la validation avant de transmettre les données contextuelles ?

J'ai une méthode d'usine simple, mais elle repose sur un arbre de configuration qui lui est transmis pour décider de l'objet à instancier.

Il pourrait y avoir une situation où le xml de configuration pourrait être bien formé, mais pas dans le format correct que l'usine attend et je ne sais pas où cela devrait être validé.

Answer 1

Lorsque l'on utilise le modèle de la fabrique, celle-ci doit-elle contenir une logique de validation ou faut-il laisser les classes appelantes s'occuper de la validation avant de transmettre les données contextuelles ?

Il existe deux alternatives distinctes pour organiser la validation :

1. La validation en tant que processus distinct

Il existe une méthode de validation distincte Validate(Config) . Cette méthode est appelée avant la méthode de construction et renvoie l'information si Config est valide ou non. Si Validate renvoie que Config est valide, alors la méthode de construction est appelée. Toute erreur pendant le processus de construction est considérée comme une exception.

2. La validation dans le cadre du processus de construction

Il n'y a pas de méthode de validation séparée. Au lieu de cela, la validation est effectuée dans la méthode de construction lorsque cela est nécessaire. Méthode de construction est autorisé à échouer et de retourner soit un objet construit, soit un résultat indiquant une erreur.

La deuxième variante peut être joliment mise en œuvre à l'aide de monades, avec une surcharge de code et de performance quasi nulle.

Answer 2

Qu'entendez-vous par validation ? Et qu'est-ce qui vous fait penser que le code qui fait partie d'une instance du design pattern Factory est différent de tout autre code ?

Si vous entendez par validation la vérification des valeurs d'entrée lues par l'utilisateur ou un fichier d'entrée, la réponse est la suivante pas de le code d'analyse syntaxique de l'entrée est responsable de la validation, et non une usine qui utilise ensuite les valeurs lues.

Si vous entendez par validation le fait que les méthodes de l'usine vérifient que leurs appelants ont fourni des valeurs conformes aux conditions préalables de ces méthodes, la réponse est la même que pour toute autre méthode qui impose des conditions préalables à ses arguments : le style consensuel pour Java est que les méthodes vérifient leurs conditions préalables et lancent une erreur de type RuntimeException si les conditions préalables ne sont pas remplies.

En pratique, cela signifie que certaines valeurs d'entrée seront vérifiées deux fois. D'abord par le code de validation de l'entrée, et ensuite par les vérifications de précondition de l'usine. C'est en partie le coût de la décomposition du code en modules (ici, un module d'entrée et une couche de service séparés).

Mais il permet aussi aux contrôles de faire des rapports différents, plus appropriés à leurs objectifs.

• Un échec de la vérification de la condition préalable (dans l'usine dans ce cas) indique un bogue dans le programme. Nous voulons que l'échec de la précondition soit signalé rapidement et durement, avant que l'état du programme ne soit modifié, afin d'obtenir les informations les plus utiles pour le débogage (dans de nombreux cas, l'emplacement du bogue sera une méthode dans la pile d'appels).
• Pour les échecs de validation de l'entrée, nous voulons typiquement que le programme signale autant de défauts dans l'entrée qu'il le peut pour une analyse de l'entrée, afin que l'utilisateur puisse les corriger tous. Pensez au compilateur que vous utilisez : vous seriez frustré s'il s'arrêtait après avoir trouvé la première erreur de syntaxe dans votre code source. Lancer des exceptions pour mettre en œuvre cette méthode est inapproprié. Le code doit prendre note de l'erreur et poursuivre l'analyse, si possible, plutôt que de s'éjecter vers une partie supérieure du programme (ce que fait le lancement d'une exception).

Answer 3

Pourquoi ne pas proposer les deux ? Ainsi, vous laissez à l'appelant le soin de décider s'il souhaite ou non que sa contribution soit validée.

Prenez cet exemple d'Apache Commons - InstantiateFactory :

Ses constructeurs par défaut n'offrent aucune validation :

InstantiateFactory(java.lang.Class classToInstantiate)

Constructeur qui exécute aucune validation .

Mais offre une validation dans getInstance :

statique Usine getInstance (java.lang.Class classToInstantiate, java.lang.Class[] paramTypes, java.lang.Object[] args)

Méthode d'usine qui effectue la validation .