PHP Enums: Beyond Simple Name and Value

When PHP introduced Enums in PHP 8.1, they quickly became a better alternative to constants or string-based flags. Instead of scattering values like "active" or "inactive" across the codebase, developers could define them in a single, strongly typed structure.

However, many developers still use enums only for their basic purpose: storing a name and a value. What is often overlooked is that enums in PHP are full objects. That means they can contain methods and logic, allowing them to carry additional meaning beyond a simple identifier.

This opens the door to a cleaner and more object-oriented way of attaching metadata to enum cases.

The Common Problem

Imagine you have a Status enum that represents whether something is active or inactive. In many real applications, these statuses often carry additional meaning. Perhaps one status has higher priority, a different score, or a different display order.

A common approach is to store this extra information somewhere else in the application, such as helper functions, configuration arrays, or switch statements scattered throughout services.

While that works, it spreads knowledge about the enum across multiple places in the codebase. Over time, that makes the system harder to maintain.

Embedding Behavior Directly in the Enum

A cleaner solution is to keep the related logic inside the enum itself. Because enums can contain methods, we can attach behavior directly to each case using a match expression.

Here is a simple example:

enum Status: string
{
    case ACTIVE = 'active';
    case INACTIVE = 'inactive';    public function getWeight(): int
    {
        return match($this) {
            self::ACTIVE => 1,
            self::INACTIVE => 0,
        };
    }
}

Now the additional information — in this case a weight value — lives directly alongside the enum cases that define it.

Using the enum becomes straightforward:

echo Status::ACTIVE->getWeight(); // Output: 1

Instead of looking up values elsewhere, the enum itself becomes the source of truth.

Why This Approach Works Well

The biggest benefit of this pattern is encapsulation. The data and the behavior related to a status are defined in the same place. When someone reads the enum, they immediately understand the additional meaning behind each case.

Another advantage is type safety. Because the logic lives inside the enum, you avoid loose arrays or magic numbers floating around your services. Every reference to the enum is strongly typed, making the system more predictable.

Readability also improves. Using match($this) clearly expresses that each enum case has a specific outcome. PHP will even warn you if a case is missing from the match expression, helping prevent subtle bugs when new enum values are added later.

Treating Enums as Domain Objects

Once you start thinking of enums as objects rather than simple constants, they become powerful tools for modeling domain logic. Instead of merely labeling states, enums can describe how those states behave.

For example, a payment status enum could define whether it is refundable. A task priority enum could determine its sorting order. A user role enum could determine permission levels.

Each case becomes more than a label. It becomes a meaningful part of the system’s design.

Final

PHP enums are often introduced as a way to replace constants, but their real strength lies in their ability to carry behavior alongside values. By embedding small pieces of logic directly inside the enum, you keep related concepts together and reduce the need for scattered helper code.

Sometimes the best object-oriented design is not about adding more classes. It is about giving existing structures the responsibility they naturally belong to.

And in many cases, enums are the perfect place to start.