Der Aufruf einer Programmmethode wird beim Factory Pattern gänzlich von der Implementierung neuer Klassen separiert, was einige Vorzüge mit sich bringt. So wirkt sich dieser Umstand insbesondere auf die Erweiterbarkeit einer Software aus: Factory-Instanzen besitzen ein hohes Maß an Eigenständigkeit und erlauben das Hinzufügen neuer Klassen, ohne dass sich die Applikation hierfür in irgendeiner Weise ändern muss – parallel zur Laufzeit. Es genügt, die Factory-Schnittstelle zu implementieren und den Creator entsprechend zu instanziieren (via ConcreteCreator).
Ein weiterer Vorteil besteht in der guten Testbarkeit der Factory-Komponenten. Implementiert ein Creator beispielsweise drei Klassen, so lässt sich deren Funktionalität einzeln und unabhängig von der aufrufenden Klasse testen. Bei letzterer ist lediglich sicherzustellen, dass sie den Creator ordnungsgemäß aufruft, selbst wenn die Software an dieser Stelle zu einem späteren Zeitpunkt erweitert wird. Ebenfalls vorteilhaft ist die Möglichkeit, Fabrikmethoden (anders als bei einem Klassen-Konstruktor) mit einem aussagekräftigen Namen versehen zu können.
Die große Schwäche des Factory Design Patterns ist die Tatsache, dass seine Umsetzung zu einem starken Anstieg der eingebundenen Klassen führt, denn jedes ConcreteProdukt erfordert immer auch einen ConcreteCreator. So gewinnbringend der Factory-Ansatz hinsichtlich der Erweiterung einer Software grundsätzlich ist, so nachteilhaft ist er außerdem, wenn es um den aufzubringenden Aufwand geht: Soll eine Produktfamilie ergänzt werden, müssen nicht nur die Schnittstelle, sondern auch alle untergeordneten ConcreteCreator-Klassen entsprechend angepasst werden. Eine gute Vorausplanung hinsichtlich der benötigten Produkttypen ist folglich unverzichtbar.