[PHP Guidelines series] Abstract Factory design pattern - and why it's bad

As announced here, I have started working on a series of posts related to good and bad development practices.

Abstract Factory design pattern

The second design pattern covered by this series of articles is the Abstract Factory design pattern. The main article, its sub-articles and an extensive amount of practical examples (which you can run either directly or from a bundled Docker container) is available at: https://github.com/constup/php-guidelines/tree/master/src/DesignPatterns/Creational/AbstractFactory

Abstract Factory design pattern is one of the 23 well known design patterns covered in many books and online resources. That, however, doesn't stop it from being deeply flawed, poorly named and architecturally inconsistent. Abstract Factory repository section contains:

• Theoretical definition of the Abstract Factory design pattern with practical (runnable examples);
• Analysis of its name, definition and components;
• A viable alternative (Service Bundle) defined in detail and compared to the Abstract Factory design pattern;
• Runnable code examples and deep analysis of working with both the Abstract Factory and Service bundle approach through a series of articles on real world use when:
  • adding a new property;
  • adding a new family;
  • adding a new family member;
  • adding a new Product;
  • adding a new subfamily;
  • working with methods common to more than one Product, family and/or subfamily.

All of this and more has been covered in the repository. I will just copy the conclusions here, but you are welcome (and encouraged) to read through the articles in the repository and run through the provided examples.

This is the most comprehensive coverage of actually working with Abstract Factories that you will find online or offline.

Conclusions from the repository

Abstract Factory design pattern seems like a creative and effective way to manage families of products, but it really is not. It is a half-way implemented Service Bundle which has many architectural and practical limitations. Working around these limitations, if at all possible, is difficult and can lead, in many cases, to code quality degradation over time. By using encapsulation, as defined in OOP theory, it also promotes creation of monster classes with multiple responsibilities without any defined, structured way to handle the complexity and modularize the code.

It has an incomplete definition (missing family name property, missing inclusion of Family Resolver in its list of components), and is named contrary to any logic or standards.

Abstract Factory design pattern suffers form architectural inconsistency - it uses and promotes encapsulation, but at the same time recommends treating Factories as special cases (separate services). It is defined as a creational design pattern, but also manages service (functionality) classification as a side effect.

Code architecture is forced to follow a fixed family classification and is not flexible enough to properly support functionality which breaks this classification. Real-world usability is, thus, limited.

It also suffers from unnecessary code repetition.

This article and its sub-articles have demonstrated, through practical examples, that using a Service Bundle is a much more effective, more flexible and more practical way to achieve the same things as Abstract Factory.

If you liked the article,...