Stop Using If-Else Chains: Use the Register Pattern in Python Instead

# Introduction

Every Python codebase has this problem. A slow-starting job. Two branches, maybe three. Then someone adds a case, someone adds another, and a year later you get 200 lines if/elif/else that no one wants to touch. Here is an example:

def get_model(name):
    if name == "logreg":
        return LogisticRegression()
    elif name == "random_forest":
        return RandomForestClassifier()
    elif name == "svm":
        return SVC()
    elif name == "xgboost":
        return XGBClassifier()
    # ... 15 more branches
    else:
        raise ValueError(f"Unknown model: {name}")

And yes, it works. But it also breaks Open/Closed Systemwhich means that software entities (classes, modules, and functions) must be open for extension but closed for modification. There is a better way to handle this problem: i registration pattern. This article covers what the register pattern is, how to build it from a five-line dictionary to a production-grade reusable class, and where it really deserves its place in your code. So, let's begin.

# The Problem With Chains If Else

A long conditional chain fails in a few specific ways:

• Violates the Open/Closed Principle. A new case, a new edit on a function that has already worked. Yesterday's tested code is opened, retested, and updated again. The unit of change should be “add file,” not “modify central dispatcher.”
• It piles unrelated logic into one place. Mention that your payment provider includes credit cards, PayPal, and crypto. Now three domains that have nothing to do with each other share a single function. I elif the ladder forces them to share a room anyway.
• It measures badly. Every new branch adds to the mental weight of the whole work. Twenty branches are twenty things you have to scroll through every time you debug a third branch number.
• It cannot be expanded externally. Submit a hardcoded library get_model() chain and your users are caught. They can't add their model without a monkey wrench or a fork. The logic is off.

The registration pattern adjusts the four by inverting the relationship. Instead of the dispatcher being aware of every option, each option announces itself to the dispatcher.

What is the registration pattern?

It's basically a central lookup table that sets the keys for objects (functions, classes, conditions), where each object registers itself instead of being hard-coded into something conditional. In Python, that lookup table is always a dictionary, and “register” is often done with a decorator.

# From If-Else to Dictionary

A very small win is to exchange the chain for a dictionary. One step, and the line scan is gone:

MODEL_REGISTRY = {
    "logreg": LogisticRegression,
    "random_forest": RandomForestClassifier,
    "svm": SVC,
    "xgboost": XGBClassifier,
}

def get_model(name):
    try:
        return MODEL_REGISTRY[name]
    except KeyError:
        raise ValueError(
            f"Unknown model: {name!r}. "
            f"Available: {list(MODEL_REGISTRY)}"
        ) from None

This is already a registry — just manually maintained. Dispatch is O(1), options are visible with list(MODEL_REGISTRY)and the dispatcher does not change. There remains one wart: every new model still means to edit the command and import its class at the top of the file. You can do better by allowing each component to register itself.

# Building a Decoration-Based Registry

This is the version you will actually use every day. Registration happens in the decorator, so every function or class declares its own key where it is defined:

PAYMENT_HANDLERS = {}

def register(payment_type):
    def decorator(func):
        PAYMENT_HANDLERS[payment_type] = func
        return func
    return decorator

@register("credit_card")
def charge_credit_card(amount):
    return f"Charged ${amount} to credit card"

@register("paypal")
def charge_paypal(amount):
    return f"Charged ${amount} via PayPal"

@register("crypto")
def charge_crypto(amount):
    return f"Charged ${amount} in crypto"

def process_payment(payment_type, amount):
    handler = PAYMENT_HANDLERS.get(payment_type)
    if handler is None:
        raise ValueError(f"Unknown payment type: {payment_type!r}")
    return handler(amount)

See what has changed. I process_payment the dispatcher is four lines, and will never grow. Looking for Apple Pay? Write a new function, hit @register("apple_pay") in it, paste it into any file you like, and you're done. No central list can be edited. No conflict is included. No verified unlock code. The holder stays close to its key, which is where the next student will look for it.

# Creating a Reusable Registration Class

Once you have two or three registries lying around, you'll get tired of rewriting the same boilerplate for decoration. Wrap it in a smaller class and get collision detection, better error messages, and a cleaner API for free:

class Registry:
    """A reusable name-to-object registry."""

    def __init__(self, name):
        self.name = name
        self._registry = {}

    def register(self, key):
        def decorator(obj):
            if key in self._registry:
                raise KeyError(
                    f"{key!r} already registered in {self.name!r}"
                )
            self._registry[key] = obj
            return obj
        return decorator

    def get(self, key):
        if key not in self._registry:
            raise KeyError(
                f"{key!r} not found in {self.name!r}. "
                f"Available: {list(self._registry)}"
            )
        return self._registry[key]

    def __contains__(self, key):
        return key in self._registry

    def keys(self):
        return self._registry.keys()

Now use it to create a fully configuration-driven text processing pipeline:

transforms = Registry("transforms")

@transforms.register("lowercase")
def to_lower(text):
    return text.lower()

@transforms.register("strip")
def strip_whitespace(text):
    return text.strip()

@transforms.register("remove_digits")
def remove_digits(text):
    return "".join(c for c in text if not c.isdigit())

# The pipeline is now just data. It could come from a YAML file,
# a CLI argument, or a database row.
pipeline = ["strip", "lowercase", "remove_digits"]
text = "  Order #4521 CONFIRMED  "

for step in pipeline:
    text = transforms.get(step)(text)

print(repr(text))

Output:
'order # confirmed'

This is where the pattern pays for itself. Program behavior is now defined by data – a list of strings – not by code. Reorganizing a pipeline, adding a step, or giving everything to a non-programmer with a configuration file all becomes trivial.

# Automatically Registering for Classes With __init_subclass__

When your registration holds classes instead of functions, Python has an even smoother trick. I __init_subclass__ hook (available since Python 3.6) fires automatically every time a subclass is defined, so subclasses register themselves without a decorator at all:

class DataLoader:
    _registry = {}

    def __init_subclass__(cls, fmt=None, **kwargs):
        super().__init_subclass__(**kwargs)
        if fmt:
            DataLoader._registry[fmt] = cls

    @classmethod
    def get_loader(cls, fmt):
        if fmt not in cls._registry:
            raise ValueError(
                f"No loader for {fmt!r}. "
                f"Available: {list(cls._registry)}"
            )
        return cls._registry[fmt]

class CSVLoader(DataLoader, fmt="csv"):
    def load(self, path):
        return f"Loading CSV from {path}"

class JSONLoader(DataLoader, fmt="json"):
    def load(self, path):
        return f"Loading JSON from {path}"

class ParquetLoader(DataLoader, fmt="parquet"):
    def load(self, path):
        return f"Loading Parquet from {path}"

loader = DataLoader.get_loader("parquet")
print(loader.load("sales.parquet"))   # Loading Parquet from sales.parquet

There is no decorator anywhere. Subclassing DataLoader with fmt= argument is sufficient to register a new class. This is how many frameworks build their plugin systems under the hood.

# Where Registration Patterns Are Useful When Working

This is not an academic work. It's the core of the tools you already use.

• Preparation of machine learning tests. Face Transformers For Hugs, The detectron2again MMDetection all use registries to select a model, optimizer, or extension by string name in a YAML file. build_model({"model": "resnet50"}) he beats a giant if backbone == ... block, and allows researchers to add properties without touching the trainer.
• File format and export of the editor. Map extensions like "csv", "json"again "parquet" in loading classes. Support for the new format is “write one section,” not “edit loader.”
• Web framework routing. A flask's @app.route("/users") again Click's @cli.command() hidden registries. The decorator assigns the URL or command name to the function it handles.
• Plugin architectures. Any system “drop the file into this folder and it just runs” – whatever pytest buildings, Air flow operators, or serializer backends – are almost always part of the registry collection during import.
• Event handlers and country equipment. Map event names or task management regions instead of grouping them. The transition table turns into a readable dictionary rather than a nest of criteria.

# Practical Considerations and Things to Be Aware of

• Registration takes place only on admission. The decorator runs when Python uses the file it resides in. If your handlers stay in the middle handlers/apple_pay.py and nothing ever imports that module, i @register the decorator does not fire and the holder is quietly lost. The fix is ​​to make sure that the registry modules are imported – usually with an explicit package import __init__.pyor a small detection loop with pkgutil.iter_modules which imports everything into the plugin folder.
• Beware of silent overwrites. With clear dict, two components that register the same clobber key without peeking. Since i Registry class above shows, raising the duplicate key turns a confusing runtime error into an obvious error at import time.
• Show people what's available. Always display the keys with list(registry.keys()) and include them in your error messages. “Unknown model: 'lgbm'. Available: [‘logreg’, ‘random_forest’, ‘xgboost’]”saves more time debugging than nothing KeyError.
• Don't reach for it too early. Enrollment is concentrated in two or three stable branches with a truly distinct logic. If the branches do not have a common signature, or the conditions are wider than different keys (if score > 0.9 ... elif score > 0.5 ...), the obvious criterion is clear. Enrollment is successful in one particular case: you send an explicit key to a mutable behavior, and expect that behavior set to grow.

# Wrapping up

The subscription pattern is a growing, moderate, difficult-to-expand trade if/elif/else a series of lookup tables that fill in the parts themselves. The payment is concrete. Your dispatcher stops changing. New features appear as new files instead of editing old ones. The behavior becomes something you can drive from the config. And users of your code get a real extension point instead of a locked door.

Start small. The next time you find yourself typing a third time elif name == ...stop and ask if the dictionary can do it. Usually it would be. From there, decorator versions and versions are far and wide.

# Before
if kind == "a": ...
elif kind == "b": ...
elif kind == "c": ...

# After
@registry.register("a")
def handle_a(): ...

Your future self, which scrolls through a four-line navigation bar instead of a 200-line ladder, will thank you.

Kanwal Mehreen is a machine learning engineer and technical writer with a deep passion for data science and the intersection of AI and medicine. He co-authored the ebook “Increasing Productivity with ChatGPT”. As a Google Generation Scholar 2022 for APAC, he strives for diversity and academic excellence. He has also been recognized as a Teradata Diversity in Tech Scholar, a Mitacs Globalink Research Scholar, and a Harvard WeCode Scholar. Kanwal is a passionate advocate for change, having founded FEMCodes to empower women in STEM fields.