A system often starts with one ordinary case and one exception. A customer has a normal pricing plan unless the account is a guest. A shipment has a delivery date unless it is pickup-only. A report has an owner unless it is generated by the system.

The first exception is usually harmless. The problem appears when the same check spreads through the code. Every caller asks whether it has the exceptional case before deciding what to do. Adding a new operation then means finding another place where the condition must be repeated.

One useful refactoring is to model the exceptional case as an object that supports the same behavior as the ordinary case. This is often called the Special Case pattern. Instead of making every caller recognize the exception, the special-case object knows how that case behaves.

This article explains how to recognize that opportunity, how to introduce the pattern safely, and when an ordinary conditional is still the simpler design.

Repeated recognition is the real smell

Consider a checkout flow where an order may belong to a registered customer or a guest. The code needs a display name and a discount rate.

A simple version might look like this:

if order.customer is null:
    name = "Guest"
else:
    name = order.customer.display_name

if order.customer is null:
    discount_rate = 0
else:
    discount_rate = order.customer.discount_rate

Nothing is technically wrong with these conditions. They are explicit and easy to understand.

The design pressure comes from repetition. Imagine that invoice generation, email formatting, tax calculation, audit logging, and checkout all perform similar guest checks. Each place has to know two things: how to recognize a guest and what guest behavior should be for the operation it is performing.

That duplicates knowledge. If guest behavior changes, developers must locate every branch that encodes part of the rule.

A useful signal is therefore not simply “there is an if.” It is:

  • the same exceptional condition is recognized in several places;
  • callers repeatedly choose between ordinary and exceptional behavior;
  • the exceptional behavior is stable enough to name;
  • both cases can sensibly answer the same operations.

When those conditions hold, moving the distinction behind a shared behavioral interface can reduce the number of places that need to understand the exception.

Give the special case the same contract

The mental model is straightforward: callers should ask for behavior, not first ask which kind of object they received.

Suppose registered customers already provide these operations:

customer.display_name()
customer.discount_rate()

A guest can provide the same operations:

GuestCustomer:
    display_name():
        return "Guest"

    discount_rate():
        return 0

Now the checkout code becomes:

name = order.customer.display_name()
discount_rate = order.customer.discount_rate()

The caller no longer needs to recognize the special case. The distinction still exists; it has moved to the object that represents it.

This is the core idea of the pattern. The ordinary object and the special-case object share a contract, while each provides behavior appropriate to its own case.

The example is intentionally small. In production code, the shared contract might be expressed through an interface, protocol, base type, or simply a set of operations that callers rely on. The pattern does not depend on a particular language feature.

Create the special case at a clear boundary

Removing repeated checks only helps if the system has a reliable place to decide which object to create.

Suppose customer lookup currently returns either a customer or null:

customer = customer_repository.find(customer_id)

One option is to normalize that result immediately:

customer = customer_repository.find(customer_id)

if customer is null:
    customer = GuestCustomer()

Everything after this point can work with the shared customer behavior.

An even stronger boundary may be a repository operation whose contract already promises a usable customer representation:

customer = customer_repository.find_or_guest(customer_id)

Whether that API is appropriate depends on the domain. A repository should not silently turn every missing record into a guest if “customer not found” is sometimes an error. The important design decision is to perform the conversion where the meaning of absence is known.

That distinction prevents a common mistake: treating all missing values as the same special case.

For example, these situations may require different outcomes:

anonymous checkout        -> GuestCustomer
unknown customer ID       -> error
removed customer account  -> DeletedCustomer or error
repository unavailable    -> operational failure

A Special Case object represents a meaningful domain case. It should not hide unrelated failures.

Move behavior one operation at a time

A safe refactoring does not require converting every branch at once.

Assume callers currently contain this logic:

if customer is null:
    discount_rate = 0
else:
    discount_rate = customer.discount_rate()

First introduce a GuestCustomer that implements discount_rate(). Then normalize the customer at one well-defined boundary. Finally simplify the caller:

discount_rate = customer.discount_rate()

Run the relevant tests before moving another behavior such as display_name().

This sequence matters because the refactoring changes representation as well as control flow. Doing it incrementally makes it easier to distinguish a behavioral regression from a mechanical mistake.

The same approach works when the special case already has a sentinel value instead of null. For example, code may repeatedly check customer.type == "guest". The opportunity is still about repeated recognition, not about null values specifically.

Keep behavior inside the shared contract

A special-case object is useful only while callers can treat it like the ordinary object for the operations they actually need.

Suppose later code requires a billing address:

address = customer.billing_address()

What should GuestCustomer.billing_address() return?

There is no universal answer. Returning a fake address just to satisfy the interface would hide a real requirement. Throwing an exception from an operation that callers reasonably expect to work may merely move the conditional into a less visible form.

Instead, examine the contract. Perhaps billing is impossible for guests until an address is supplied separately. In that case, a common Customer abstraction that promises billing_address() for every implementation may be too broad.

The decision should follow the domain behavior:

  • If a meaningful guest result exists, implement it.
  • If the operation does not make sense for guests, do not pretend that it does.
  • If only some workflows require the operation, consider a narrower interface or a different object for that workflow.

The pattern removes accidental branching. It should not erase meaningful differences between cases.

Distinguish a Special Case from a default value

A default value and a Special Case object can look similar because both avoid missing data, but they solve different problems.

A default value fills in data:

currency = request.currency or "USD"

A Special Case object supplies behavior for a meaningful case:

customer = GuestCustomer()
discount_rate = customer.discount_rate()

If all you need is a simple fallback scalar, introducing an object adds unnecessary machinery. The pattern earns its cost when several related operations need coherent behavior for the same exceptional case.

This distinction also helps prevent over-modeling. Not every optional field deserves a new type.

Watch for special cases that accumulate unrelated responsibilities

Once a GuestCustomer exists, it can become tempting to put every guest-related rule inside it. That can create a different problem.

For example, these operations may belong to different concerns:

display_name()
discount_rate()
checkout_redirect_url()
analytics_segment()
email_template_name()

The fact that all five vary for guests does not automatically mean they belong to one object. If the ordinary customer object would not naturally own analytics segmentation or UI navigation, the guest object probably should not own them either.

Use the same responsibility test for the special case that you would use for the ordinary object. The pattern should centralize behavior that belongs to the abstraction, not become a container for every branch involving the exceptional condition.

Consider more than one special case carefully

A design may begin with GuestCustomer and later gain DeletedCustomer, SuspendedCustomer, and ImportedCustomer.

That is not automatically a problem. Distinct cases can be useful when they have distinct, stable behavior. But a growing family of special-case classes can also signal that the system is modeling a state machine indirectly.

Ask what is changing.

If each case represents a durable identity with coherent behavior, separate objects may remain clear. If objects frequently transition between these cases and many operations depend on the current state, explicit state modeling may communicate the lifecycle better.

The pattern is strongest when it represents a small number of meaningful alternatives, not when it is used to avoid every conditional in a complex workflow.

Do not hide failures behind harmless behavior

A dangerous Special Case is one that makes a failure look successful.

Suppose a permissions service fails. Returning GuestCustomer because no customer data was obtained would be misleading: the system did not discover that the user was a guest; it failed to determine who the user was.

Likewise, a payment lookup failure should not become a NoPayment object if the absence of payment and inability to query payments have different consequences.

A useful rule is to ask whether the special case is a valid business state that the system can identify confidently. If it is actually an infrastructure failure, invalid input, or violated invariant, preserve that failure instead of converting it into ordinary behavior.

This boundary is important for reliability. Removing conditionals is never worth losing information about an error.

When a conditional is better

The Special Case pattern has a cost: another concept, another implementation, and a contract that must make sense across ordinary and exceptional cases.

Keep the conditional when the exception appears in one place and is unlikely to spread:

label = user.nickname if user.nickname is not null else "Anonymous"

A direct expression is easier to read than introducing an AnonymousNickname abstraction.

A conditional may also be better when the exceptional behavior is highly local. If one reporting screen treats missing owners specially but the rest of the system must distinguish missing owners from real users, normalizing the value globally would remove information that other code needs.

Use the pattern when repeated recognition is creating coupling. Do not use it merely to reduce the number of if statements.

A practical decision process

When you notice the same exceptional check appearing repeatedly, trace what each branch does. If callers keep asking the same question and then choosing behavior that belongs to one abstraction, consider giving the exceptional case its own implementation.

Before doing so, verify three things. The special case must represent a legitimate state rather than a hidden failure. Its behavior must fit the shared contract without invented placeholder data. And there should be a clear boundary where the ordinary or special representation can be chosen once.

Then refactor incrementally: introduce the special case, normalize one input path, move one behavior, and remove the corresponding repeated branch. This keeps the change understandable and testable.

Conclusion

Repeated exceptional-condition checks make many callers responsible for recognizing the same case and remembering what it means. A Special Case object can move that knowledge behind a shared behavioral contract, so callers use the object without first classifying it.

The useful mental model is not “replace conditionals with objects.” It is recognize the case once, then let the case provide its own valid behavior.

Apply the pattern when the exceptional case is meaningful, recurring, and compatible with the ordinary contract. Keep a direct conditional when the exception is local or simpler. Most importantly, never use a harmless-looking special case to conceal an error that the system needs to surface.

Software Engineering Refactoring Code Quality Design Patterns