Interface Naming: Follow Your Parent Verb Pattern

Yesterday I was refactoring some code that had a messy inheritance hierarchy. A base class had a method called allowsRefund(), and a child interface was named SupportsPartialRefund.

Read that out loud: “This class allows refund, and supports partial refund.” Two different verbs for the same concept. It’s subtle, but it makes the codebase harder to scan.

The Fix

Rename the interface to match the parent’s verb:

// ❌ Mixed verbs
class PaymentGateway
{
    public function allowsRefund(): bool { ... }
}

interface SupportsPartialRefund
{
    public function getPartialRefundLimit(): Money;
}

// ✅ Consistent verb pattern
class PaymentGateway
{
    public function allowsRefund(): bool { ... }
}

interface AllowsPartialRefund
{
    public function getPartialRefundLimit(): Money;
}

Why This Matters

When you’re scanning a class that implements multiple interfaces, consistent naming lets you instantly understand the hierarchy:

class StripeGateway extends PaymentGateway
    implements AllowsPartialRefund, AllowsRecurringCharge
{
    // The "Allows" prefix immediately tells you
    // these extend the parent's capability pattern
}

If one used Supports and another used Allows, you’d waste mental energy wondering if there’s a meaningful difference. (There isn’t.)

The Rule

When naming an interface that extends a parent class’s concept, use the same verb the parent uses. If the parent says allows, the interface says Allows. If the parent says supports, the interface says Supports. Don’t mix.

Small naming consistency compounds across a large codebase.