The Simple Factory is a creational design pattern whose purpose is to centralize the object creation logic in a single point (usually a dedicated class, method, or VI). Based on a configuration, a user choice, or other input, the factory returns a corresponding concrete instance.
We refer to Simple Factory when the object creation logic is not only centralized in a single point but also includes the choice between multiple concrete classes to instantiate based on a parameter (string, enum, configuration). In this sense, it is often applied naturally and spontaneously, even without explicitly naming it.
In practice, many call the Simple Factory simply the Factory Pattern, but formally the Factory Method and the Abstract Factory are official GoF design patterns, while the Simple Factory is an informal, simpler, and more direct pattern.
Structure
The Simple Factory is a very straightforward pattern. It is a method of a class or a VI that creates objects on request. It requires an input (typically a string or enum) to decide which concrete class to instantiate. The output is the object returned by the Simple Factory.
The Simple Factory decouples the client from the concrete classes. The client only works with interfaces or base classes, making the system more flexible, extensible, and maintainable.
Real-World Example
Suppose we have an application that needs to export documents in different formats: PDF, Excel, Word, etc. The client does not need to know the details of each format but only works with the base class DocumentExporter (an interface would also suffice) to generate the document. The concrete classes CSVExporter, HtmlExporter, and PdfExporter will then be responsible for actually generating the chosen document.
The following image shows the class hierarchy involved.
The Simple Factory takes the required “type” as input and returns the correct object. In LabVIEW, the Simple Factory is implemented via a Case Structure driven by a string or enum.
The complete implementation of the example is available here: LabVIEW and C#.
Advantages and Disadvantages
Similar to the other Factories discussed, the Simple Factory has the following advantages:
- Centralization of creation logic. All the logic needed to decide which concrete class to instantiate is placed in a single point (the factory).
- Separation between client and concrete classes. The client knows what it wants (an interface or a superclass) but does not know the details of how or which concrete class is created.
- Decoupling and maintainability. If the name or implementation of a concrete class changes, only the factory needs to be modified, not all client code.
The main disadvantage of the Simple Factory is that adding a new type requires modifying the existing factory. Every time a new concrete class is introduced, you must go back to the factory and add a new case. This violates the Open/Closed principle.
Conclusion
The Simple Factory is, by its nature, a practical and immediate creational design pattern.
It emerges spontaneously as soon as the need arises to centralize object creation logic based on a type descriptor. If the system requires a concrete class (e.g., PdfExporter) to be instantiated based on an input value (e.g., the string “PDF”), the most direct and logical implementation solution is a centralized decision structure (Case Structure or switch/case). This logic, which maps the input to the correct output, is the Simple Factory.
In this sense, this pattern is the foundation, the default approach adopted whenever an input parameter acts as a selector for the class to be created.
The alternatives Factory Method and the Abstract Factory do not eliminate this selection logic; they transform it and distribute it across a class hierarchy. They only do this to achieve greater extensibility for applications that frequently need to add new types of objects.
It is interesting to note that the Simple Factory is not eliminated by the more complex patterns but is often reused at a higher level. In practice, systems that implement the Factory Method and the Abstract Factory typically use a Simple Factory to instantiate the initial object—that is, the appropriate Concrete Factory or Concrete Creator—based on a system configuration or an initial input. In this scenario, the Simple Factory acts as a launcher, deciding which factory to instantiate, and then delegating the creation of specific objects to the other, more sophisticated pattern.
For all other scenarios, where the set of products to be created is stable and known, the Simple Factory is more than sufficient and remains the simplest and most direct choice for centralizing the creation process. Understanding the simplicity and limitations of the Simple Factory is key to understanding why and when to migrate to a more sophisticated creational pattern.
