Le motif d'usine doit-il être utilisé pour désactiver la fonctionnalité?

Question

J'essaie de comprendre l'utilisation du modèle d'usine, lorsque je souhaite désactiver les fonctionnalités d'une application. Disons par exemple que j'ai une usine appelée LoggerFactory, qui crée une instance de logger.

Si la journalisation de la configuration est désactivé dans mon application:

l'usine de l'enregistreur passe en arrière une instance de l'enregistreur Si cela est un mannequin, qui ne fait rien? Tout code utilisant l'enregistreur n'a donc pas besoin d'être modifié.

Ou, est-ce la responsabilité du code utilisant l'enregistreur, de ne pas utiliser l'enregistreur s'il est désactivé dans la configuration?

Ou, est-ce la responsabilité de l'enregistreur lui-même de ne rien faire, s'il est désactivé?

Merci pour l'aide.

Answer 1

Si vous avez plusieurs classes logger différentes (par exemple, log to file et log to network), je pense que renvoyer un enregistreur factice lorsque la journalisation est désactivée est la solution la plus simple et la plus flexible. Il ne nécessitera aucune modification du code qui utilise l'enregistreur, et il ne nécessitera aucune modification des autres enregistreurs. L'idée de rendre responsable l'utilisateur de l'enregistreur est mauvaise, car cela étendrait la fonction de désactivation de la journalisation dans tout le code, polluant ainsi la logique de l'application.

Answer 2

Le code utilisant l'enregistreur ne doit pas être impliqué dans la conditionnalité activée/désactivée.

L'utilisation d'un enregistreur Dummy disabled ou d'un logger stadanrd qui sait qu'il est désactivé est moins évident. Pragmatiquement, je pense que nous aurons tendance à trouver que l'activation partielle est le scénario le plus courant - certaines destinations ou classes de message auront tendance à être émises lorsque la plupart sont désactivées. Donc, je verrais probablement cela comme le travail naturel de l'enregistreur de comprendre ce qu'il est configuré pour faire.

J'irais avec le mannequin seulement si cela rend l'implémentation de logger beaucoup plus facile et c'est un scénario d'utilisation commun.

Answer 3

À mon humble avis, ce n'est pas une question sur les principes du modèle d'usine. C'est plus une question sur la conception de votre style de codage etc. Mais, juste pour répondre à votre question de conrete: Il serait plus facile et plus intuitif et plus flexible (1) de retourner un objet comme une instance de "vide" logger class ou (2) pour vérifier l'indicateur logging-disabled-flag dans la classe logger régulière.