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

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!

© Ketki Ambekar 2025