Devrions-nous toujours utiliser une usine au lieu de créer un objet en utilisant le mot-clé "new" ?

Question

J'ai lu à de nombreux endroits que la création d'objets à l'aide du mot-clé "new" doit être évitée en général. Existe-t-il un cas où il est préférable de créer un objet directement dans le code client plutôt que d'utiliser une classe d'usine ?

Answer 1

L'intérêt des fabriques est de séparer la création d'objets de leur utilisation (logique métier). Ceci est généralement considéré comme une bonne pratique car cela permet de respecter des principes tels que Séparation des préoccupations y Responsabilité unique .

D'autre part, les usines produisent des frais généraux. Vous devez écrire (ou lire) plus de code si vous les utilisez.

Je suis sûr qu'il y a des cas où les usines ne sont pas utiles. Un cas qui me vient à l'esprit est celui des classes d'écoute d'action utilisées dans la programmation d'interface utilisateur.

Comme toujours, c'est à vous de décider dans chaque cas particulier. Posez-vous simplement la question : Cela rendra-t-il mon code plus facile à lire et à modifier ?

Vous devez également faire la distinction entre les méthodes de fabrique statiques qui ne produisent qu'une faible surcharge et les fabriques abstraites qui sont beaucoup plus compliquées.

Answer 2

La méthode Factory permet à une classe de différer son instanciation à des sous-classes. Il est donc préférable de l'utiliser lorsque l'implémentation d'une classe abstraite est sujette à des changements fréquents, si vous n'avez pas affaire à une classe abstraite avec plusieurs implémentations.

Answer 3

J'ai lu à de nombreux endroits que la création d'objets à l'aide du mot-clé 'new' doit être évitée en général. devrait être évitée en général

C'est une vision extrême de la conception de la création d'objets.
L'approche de l'usine (publique static ) doit être privilégiée par rapport aux approches par constructeur public dans les cas où cela a du sens.
En outre, dans certains cas, le modèle du bâtisseur est plus approprié qu'eux.

Je pense que vous devriez poser la question plus en termes d'utilisation de la classe.
Exposer un constructeur public signifie exposer une implémentation spécifique sans possibilité de changer l'interne (implémentation, cache, calcul ou autre) pour les clients sans casser l'API et forcer les clients à changer leur code.

Si la classe est exposée à différents clients, il est généralement déconseillé d'exposer le constructeur public d'une classe qui pourrait être adaptée, car vous ne voulez pas casser leur code existant plus tard et vous ne voulez pas non plus conserver les défauts/problèmes de l'implémentation existante.

Si la classe est une classe interne du projet, vous devriez ajouter la complexité de définir une factory ou un builder dans la classe seulement si cela apporte une valeur dans l'immédiat.
Si ce n'est pas le cas, comme il s'agit d'un interne, vous pourriez toujours remanier le code de votre pour utiliser la nouvelle méthode. Vous ne casserez pas les codes de plusieurs clients.

Existe-t-il un cas où la création d'un objet directement dans le code du client est une meilleure idée que l'utilisation d'une classe d'usine ?

Outre le champ d'utilisation, je pourrais également citer les classes de services ou les classes d'entités comme de bons candidats pour les constructeurs publics.
Les modèles anémiques et les modèles par couche (DTO par exemple) sont également de bons candidats pour favoriser les constructeurs publics. La logique et la cohérence étant assurées par les services qui le manipulent.