Forem: Ketki Ambekar

An Enum Alternative to the Factory Pattern: The Pros, Cons, and Hidden Dangers (in the voice of Rita Skeeter)

Ketki Ambekar — Thu, 04 Sep 2025 02:37:21 +0000

I wrote a blog post earlier today. During my usual AI checks, I asked Gemini if it could reframe my article in the voice of Rita Skeeter's quill.

The result was way too cool not to publish. So here's the same article in the voice of Rita Skeeter's quill:

Unmasking the Enigma of Object Creation: A Glimpse Behind the Program's Veil

One often wonders, in the hallowed halls of coding, what dark arts or cunning sorcery truly govern the birth of objects. We speak, of course, of the very essence of a program: its data ingestion. From the most mundane text dumps to the clandestine whispers from XML gateways, or even the sprawling, often scandalous, SQL data dumps – how precisely does a program select its next meal, its very source of truth?

It is whispered, among those who claim to know, that an IDataReader interface serves as a mere disguise, a super-type behind which myriad concrete classes hide their true nature. But how does one truly choose which masked player takes the stage to gather the precious data? Ah, dear reader, therein lies a tale...

The Grand Old Factory: A Rather Obvious, Yet Pervasive, Method
For decades, the engineering world has clung to a rather unimaginative approach: the Factory Pattern. A concept so straightforward, it barely warrants the title of "pattern." Imagine, if you will, a bustling (or perhaps, rust-covered and grimy) factory floor, where a designated "foreman" – a Factory class – is tasked with the rather pedestrian job of deciding which specific IDataReader to churn out.

A simple readerType variable, perhaps a whisper from an API call, or even a coded decree, dictates the foreman's action. Observe the rather blunt instrument of its logic below:


//C# (One shudders to think how many such simple constructs exist)

using FactoryPatternEnumDemo.DataReaders;
namespace FactoryPatternEnumDemo;

public static class DataReaderFactory
{
    public static IDataReader GetDataReader(string readerType)
    {
        switch(readerType)
        {
            case "CSV":
                return new CSVReader();
            case "XML":
                return new XMLReader();
            case "JSON":
                return new JSONReader();
            case "DBReader":
                return new new DBReader();
            default:
                return new AnyTextReader();
        }
    }
}

public static class DataReaderClient
{
    private static void Main(string[] args)
    {   
        //A rather uninspired creation via a Factory Class
        IDataReader dataReader = DataReaderFactory.GetDataReader("JSON");      
    }
}

A switch statement! One almost expects a polite curtsy with such predictability. This "Factory" merely serves as a glorified sorting hat, dispatching objects with a minimum of flair. And yet, its proponents claim it has its virtues...

The Enigmatic Enum: A Whisper of Modernity, a Promise of Terse Elegance
But what if, dear reader, there was another way? A path less trodden, where the very names of our data readers hold the key to their own creation? Imagine an Enum, seemingly innocent, adorned with secret annotations, each a cryptic clue to the true identity of the class it represents. A method so terse, so... modern, that it bypasses the need for an entire dedicated Factory class!

One simply invokes a generic, reusable extension method – a mere incantation – to pry open the enum's hidden truths and summon forth the desired IDataReader. Let us gaze upon this audacious display of object conjuration:


//C# (One must admit, a certain theatricality in this approach)

public enum DataReadersEnum
{
    [Description("FactoryPatternEnumDemo.DataReaders.CsvReader")]
    Csv,    

    [Description("FactoryPatternEnumEnumDemo.DataReaders.JsonReader")]
    Json,    

    [Description("FactoryPatternEnumDemo.DataReaders.XmlReader")]
    Xml,    

    [Description("FactoryPatternEnumDemo.DataReaders.DbReader")]
    Db,
        [Description("FactoryPatternEnumDemo.DataReaders.AnyTextReader")]
    AnyText    
}

public static class DataReaderExtensions
{
    public static string GetClassName(this DataReadersEnum source)
    {
        FieldInfo fi = source.GetType()?.GetField(source.ToString());

        DescriptionAttribute[] attributes = (DescriptionAttribute[])fi.GetCustomAttributes(
            typeof(DescriptionAttribute), false);

        if (attributes != null && attributes.Length > 0) return attributes[0].Description;
        else return string.Empty;
    }
}

public class DataReaderClient
{
    private static void Main(string[] args)
    {   
        //Oh, the intrigue! Object creation using the secrets hidden within the Enum's annotations
        string dataReaderClassName = DataReadersEnum.Json.GetClassName(); // Note the fix to DataReadersEnum
        Type type = Type.GetType(dataReaderClassName); 
        IDataReader dataReader2 = (IDataReader) Activator.CreateInstance(type);
    }
}

A slight correction in the code snippet above, as the infamous quill often errs in its haste to reveal a juicy detail.

This method, so deceptively simple, promises dynamic object creation through the arcane art of Reflection. But, dear reader, does brevity truly equate to brilliance? Or does a more sinister truth lurk beneath its gleaming surface? We shall now compare these two contenders, exposing their strengths and weaknesses for all to see.

The Factory Pattern: Its Unflappable Virtues (And its Mundane Flaws)

Let us not be entirely dismissive of the old guard. The Factory Pattern, despite its lack of dramatic flourish, offers certain undeniable advantages:

A Cloak of Decoupling: It shrewdly separates the client from the nitty-gritty of object instantiation. One need not dirty one's hands with the specifics, leaving the main code blissfully ignorant of how its data readers are truly born.

The Unbreakable Vows of SOLID: This pattern, it is said, adheres to the sacred principles:

Single Responsibility: The client merely uses objects; the factory creates them. A clear division of labor, one might say, quite unlike some of the more... multitasking individuals we've encountered.

Open/Closed: One merely adds another case to the venerable switch statement to extend its functionality. No need to disturb the existing, established order.

Dependency Injection: It plays rather nicely with this concept, allowing for a more controlled environment.

The Economy of Repetition: Why repeat oneself when a single factory can handle the chorus of object creation? The DRY principle, they call it.

A Predictable Pedigree: Objects are born in a centralized, almost clinical, environment. One can ascertain their behavior at compile time, eliminating any "sudden surprises" that might disrupt a well-ordered program. All in all, rather easy to maintain and, dare I say, test.

But even the most steadfast of institutions have their detractors:

The Unnecessary Extra Class: For those who prefer minimalist elegance, an entire extra class just for creation seems... superfluous.

The Shadow of Modern DI: While it supports Dependency Injection, some whisper that it's a tad old-fashioned compared to the sleek, automated offerings of modern DI frameworks.

The Looming 'God' Factory: A terrifying prospect indeed! As an application expands, this single factory can balloon into a monstrous entity, a central nexus of change that becomes an unbearable burden. A maintenance nightmare, pure and simple.

The Enum Technique: A Dazzling Promise, A Hidden Peril?

Now, for the dazzling newcomer. The Enum technique, with its air of effortless grace, certainly makes a grand entrance:

The Illusion of Open/Closed: Ah, here's the true allure! One simply adds a new entry to the enum, whispers a new class name into its description, and voilà! No messy switch statements to disturb. The core creation logic remains untouched, seemingly "closed for modification." A truly elegant sleight of hand.

The Promise of Terse Code: The sheer lack of explicit case statements does indeed present an image of reduced boilerplate, particularly for those who admire conciseness above all else.

But, dear reader, peel back the layers of this dazzling façade, and a more troubling truth emerges:

The Fragile Threads of Type Safety: This delicate dance relies on the precarious string matching of data annotations. A simple rename, a careless typo in a class name, and your program descends into chaos—not with a reassuring compile-time shriek, but with a silent, insidious runtime failure. A bug, perhaps, that will only reveal itself when the lights go out, and the clients begin to scream. The IDE, that trusty sentinel, remains utterly oblivious to this impending doom.

The Performance Bog of Reflection: To peer into the soul of an assembly, to pluck class names from the ether, requires Reflection. A technique whispered about with caution, for it is notoriously slow. Like wading through treacle while others fly, it can cause a "quadratic runtime" when least expected. Though some claim modern .NET has polished this particular dark art, the experienced will tell you: when in doubt, assume Reflection is slow. Especially when dealing with collections; one shudders to contemplate the potential for sluggish, unresponsive applications.

The Labyrinth of Debugging: When things inevitably go awry, tracing the ethereal path of Reflection is no task for the faint of heart, or indeed, the less seasoned eye. It demands a dry-run, a careful prodding of the beast, often leading to the inadvertent activation of sensitive code. Imagine, if you dare, an intern, brimming with naive curiosity, accidentally unleashing a torrent of ill-timed emails upon the entire production user base! A reputational catastrophe, all for the sake of a "terse" solution.

In Conclusion: The Unvarnished Truth

After this candid exposé, you, dear reader, will have undoubtedly arrived at the inescapable truth. While the Enum technique presents a tempting allure of brevity and dynamic flair, it is, in its essence, a treacherous anti-pattern. It sacrifices the robust predictability of type safety and the swift efficiency of direct instantiation for a fleeting illusion of simplicity.

The Factory Pattern, though perhaps less dramatic, remains the recommended and dependable stalwart. It may introduce an extra class, it may require the occasional tweak to a switch statement, but it grants you the invaluable gifts of compile-time safety, predictable performance, and a codebase that won't send your debugging efforts into a reflective, quadratic spiral. One might even call it... responsible.

One should, therefore, regard the dynamic object creation using Enums with the utmost suspicion. To use it is to invite chaos, to flirt with disaster. Practicality dictates: you can safely and practically read that as 'never'.

The working demo of the code discussed in this rather enlightening article can be obtained, for your own investigations, at this link.

Got thoughts? I'd love to hear from you in the comment section below. And do bring your own scandalous revelations!

Happy coding!

An Enum Alternative to the Factory Pattern: The Pros, Cons, and Hidden Dangers

Ketki Ambekar — Wed, 03 Sep 2025 21:31:09 +0000

The Factory Pattern is a go-to solution for creating objects, but what if there were a way to make it more flexible and scalable? Let's explore how an enum can be used to drive a dynamic object creation process.

Say you have a program that wants to ingest some data. The said data could be read from a variety of sources and formats, like text dumps, PDF files, XML gateways, SQL data dumps, text scraped from websites, etc.

With an interface IDataReader as our super type, we could create a separate concrete class for reading each type of data. Let's talk about selecting the right concrete class for reading data in the calling client class.

The Factory Pattern Technique:

Typically, you'd go about implementing this by creating a Factory class. To put it simply, it is a class that takes care of the logic by which we determine which object to create. In the example below, we determine which concrete object of the IDataReader type needs to be returned using a factory class that employs a switch logic. The driving variable of the switch statement, called readerType could be configured or received through an API call, among other ways.


//C#

using FactoryPatternEnumDemo.DataReaders;
namespace FactoryPatternEnumDemo;

public static class DataReaderFactory
{
    public static IDataReader GetDataReader(string readerType)
    {
        switch(readerType)
        {
            case "CSV":
                return new CSVReader();

            case "XML":
                return new XMLReader();

            case "JSON":
                return new JSONReader();

            case "DBReader":
                return new DBReader();

            default:
                return new AnyTextReader();

        }

    }

}

public static class DataReaderClient
{
        private static void Main(string[] args)
        { 
            //Example of object creation via a Factory Class
            IDataReader dataReader = DataReaderFactory.GetDataReader("JSON");     

        }
}

The Enum Technique:

Another, and a comparatively terse technique for object creation, is the Enum method. We could achieve this using only the DataReaderClient class, an Enum, and an extremely generic and reusable extension method to read the data annotations in an enum, without needing to create a separate Factory class.

Let's see the implementation of that approach in the code below.


//C#

public enum DataReadersEnum
{
    [Description("FactoryPatternEnumDemo.DataReaders.CsvReader")]
    Csv,    

    [Description("FactoryPatternEnumDemo.DataReaders.JsonReader")]
    Json,    

    [Description("FactoryPatternEnumDemo.DataReaders.XmlReader")]
    Xml,    

    [Description("FactoryPatternEnumDemo.DataReaders.DbReader")]
    Db, 
        [Description("FactoryPatternEnumDemo.DataReaders.AnyTextReader")]
    AnyText   

}

public static class DataReaderExtensions
{
    public static string GetClassName(this DataReadersEnum source)
    {
        FieldInfo fi = source.GetType()?.GetField(source.ToString());

        DescriptionAttribute[] attributes = (DescriptionAttribute[])fi.GetCustomAttributes(
        typeof(DescriptionAttribute), false);

        if (attributes != null && attributes.Length > 0) return attributes[0].Description;

        else return string.Empty;

    }
}

public class DataReaderClient
{
      private static void Main(string[] args)
      {  
          //Object creation using the data annotations in the Enum
          string dataReaderClassName =DataReaders.JSON.GetClassName();

    Type type = Type.GetType(dataReaderClassName); 

    IDataReader dataReader2 = (IDataReader) Activator.CreateInstance(type);
    }

}

NOTE: We could have used a placeholder type <T> in our extension method to make it more and truly generic, but for the sake of clarity and simplicity, we've kept it specific to the DataReaderEnum in this article.

This method allows us to create objects dynamically using reflection. Let's compare the two techniques along with their pros and cons.

The Factory Pattern: The Pros

Decoupling the calling class from concrete implementations. By separating the logic of actually creating the classes from the rest of the flow of the code, we ensure that if we ever need to add more types IDataReader classes, we need not touch the main calling code logic.

A SOLID-proof technique. This structure of code upholds the relevant SOLID principles - the Single Responsibility Principle (the caller code is separated from object creation logic), the Open/Closed Principle (we only need to add more cases to the switch statement to extend without modifying the existing statements), and the Dependency Injection Principle.

DRY? Check! DRY refers to the 'Don't Repeat Yourself' principle. The logic of object creation (the switch statement in our case) need not be repeated in multiple places where we need to create the IDataReader object(s).

Centralized object creation means that we are easily able to keep track of the objects that are created at runtime if we need to. The program runs in a highly controlled manner, and we can ascertain the behavior of the code at compile time to ensure there are no sudden surprises during runtime.

All this makes our code super easy to maintain and test.

The Factory Pattern: The Cons

We end up creating extra classes. There are some cases where this might be overkill. This can make the code harder to follow for someone new to the project.

Dependency Injection can be more complicated and outdated than what is offered by modern DI frameworks (eg, Unity Containers), which often handle object creation and dependency management automatically.

Can lead to a 'God' factory. As an application grows, there's a risk of creating a single, massive factory class responsible for creating many different types of objects. This "God" factory becomes a central point of change and a maintenance nightmare.

The Enum technique: The Pros

Adherence to the Open/Closed Principle (in a different way): This approach can be seen as highly "open for extension." You can add a new reader type simply by adding a new entry to the enum and creating the corresponding class. There is no question of modifying the factory's switch statement, which means the core creation logic remains "closed for modification."

Reduced Boilerplate for Simple Cases: When the object creation logic is a straightforward one-to-one mapping from an identifier to a class, this approach can seem less verbose than a full-fledged factory. You avoid the explicit case statement for each type in the factory.

The Enum Technique: The Cons

Loss of Type safety: Making sure the data annotation descriptions do correspond to an actual module in the assembly is a delicate operation and requires thorough testing. The IDE fails to automatically refactor any renaming operations. Any renaming operations can result in bugs that are not immediately obvious and can take some time to track down. In contrast, errors of a similar nature can be caught during compile time while using the factory class.

Performance Issues: Anytime we use reflection in any scenario, we must exercise caution. Because reflection loops through all members of an assembly, we can inadvertently and often cause a quadratic runtime. The mantra is 'reflection is slow'. Although the reflection library was refactored in the .NET 8 release and is supposed to have made the operation speedier, when in doubt, stick to the aforementioned mantra. Especially when using it with any sort of collections. Much can be said about reflection; please be on the lookout for subsequent articles where we benchmark reflection libraries from different .NET frameworks and discuss use cases and best practices for it.

Hard to debug: This is another side effect of using reflection. It's not straightforward to dry-run the code, especially for a less seasoned eye. Sometimes we are compelled to run the code to understand the flow of the code. We may inadvertently end up running some sensitive lines of code. This can potentially escalate into a reputational nightmare for an organization, think of an intern accidentally sending an email to the production user base.

In Conclusion

You might have rightly concluded by now that the factory pattern is the recommended approach over dynamic object creation using Enums. The latter is actually an anti-pattern and should not be used unless there is a dire situation. While the Enum technique may look neat in trivial cases, in production scenarios, it usually creates more problems than it solves.

The working demo of the code included in this article can be obtained at this link.

Got thoughts? I'd love to hear from you in the comment section below.

Happy coding!

Found the article too boring? Read it here in the voice of Rita Skeeter.