La vogue du modèle Factory découle d'une croyance presque dogmatique chez les développeurs de langages de type "C" (C / C ++, C #, Java) selon laquelle l'utilisation du mot-clé "nouveau" est mauvaise et doit être évitée à tout prix (ou moins centralisé). Cela, à son tour, découle d'une interprétation ultra-stricte du principe de responsabilité unique (le "S" de SOLID), ainsi que du principe d'inversion de dépendance (le "D"). En termes simples, le SRP indique qu'idéalement, un objet de code devrait avoir une "raison de changer" et un seul; cette "raison de changer" est le but principal de cet objet, sa "responsabilité" dans la base de code, et tout ce qui nécessite une modification du code ne devrait pas nécessiter l'ouverture de ce fichier de classe. Le DIP est encore plus simple. un objet de code ne devrait jamais dépendre d'un autre objet concret,
Par exemple, en utilisant "new" et un constructeur public, vous couplez le code appelant à une méthode de construction spécifique d'une classe concrète spécifique. Votre code doit maintenant savoir qu’une classe MyFooObject existe et qu’un constructeur prend une chaîne et un int. Si ce constructeur a besoin d'informations supplémentaires, toutes les utilisations du constructeur doivent être mises à jour pour transmettre ces informations, y compris celle que vous écrivez maintenant. Par conséquent, ils doivent posséder un élément valide à transmettre. Ils doivent donc posséder: soit être modifié pour l'obtenir (en ajoutant plus de responsabilités aux objets consommateurs). En outre, si MyFooObject est remplacé dans la base de code par BetterFooObject, toutes les utilisations de l'ancienne classe doivent être modifiées pour construire le nouvel objet à la place de l'ancien.
Ainsi, au lieu de cela, tous les consommateurs de MyFooObject doivent être directement dépendants de "IFooObject", qui définit le comportement de l’implémentation de classes incluant MyFooObject. Désormais, les utilisateurs d’IFooObjects ne peuvent pas simplement construire un IFooObject (sans savoir qu’une classe concrète particulière est un IFooObject, ce dont ils n’ont pas besoin); de l'extérieur, par un autre objet qui a la responsabilité de savoir comment créer le bon IFooObject pour la circonstance, qui dans notre langage est habituellement appelée usine.
Maintenant, voici où la théorie rencontre la réalité; un objet ne peut jamais être fermé à tous les types de changement tout le temps. En l'occurrence, IFooObject est désormais un objet de code supplémentaire dans la base de code, qui doit changer chaque fois que l'interface requise par les consommateurs ou les implémentations d'IFooObjects changent. Cela introduit un nouveau niveau de complexité impliqué dans le changement de la façon dont les objets interagissent les uns avec les autres à travers cette abstraction. De plus, les consommateurs devront encore changer, et plus profondément, si l'interface elle-même est remplacée par une nouvelle.
Un bon codeur sait comment équilibrer YAGNI ("Vous n'en aurez pas besoin") avec SOLID, en analysant la conception et en recherchant les endroits susceptibles de changer, et en les restructurant pour qu'ils soient plus tolérants. ce type de changement, parce que dans ce cas , « vous êtes en avoir besoin ».