Static vs Instance Methods in PHP: When Should You Use Each?

Static vs Instance Methods in PHP: When Should You Use Each?

Every PHP class you write forces you to make a choice: should this method be static or not? It seems like a small syntax decision — just add the static keyword and call it a day. But that one keyword changes how your code behaves, how it's tested, and how it scales. 89% of PHP developers now use PHP 8.x (JetBrains, 2026), yet misusing static methods remains one of the most common OOP mistakes in PHP codebases. Get this wrong, and you'll end up with code that works today but fights you every time you need to change it.

This post breaks down static vs instance methods with working PHP 8 code, real Laravel examples, performance data, and a clear decision framework you can use on your next project.

PHP OOP fundamentals

TL;DR: Use static methods for stateless utilities and factory methods. Use instance methods for everything that depends on object state. Static methods can't be mocked easily in tests — and 32% of PHP developers write no tests at all (JetBrains, 2026). Choosing correctly from the start saves painful refactors later.

What Are Static Methods in PHP?

A static method belongs to the class itself, not to any specific object created from that class. You call it using ClassName::methodName() without ever writing new ClassName(). According to the JetBrains State of PHP 2026 survey of 1,720 developers across 194 countries, Laravel leads PHP framework adoption at 64% (JetBrains, 2026) — and Laravel uses static methods extensively through its facade pattern.

Here's what a static method looks like in practice:

class MathHelper
{
    public static function percentage(float $part, float $total): float
    {
        if ($total === 0.0) {
            return 0.0;
        }

        return round(($part / $total) * 100, 2);
    }
}

// Call without creating an object
$result = MathHelper::percentage(45, 200); // 22.5

Notice there's no $this anywhere. A static method can't access instance properties or call instance methods. It lives in the class's namespace, takes input through parameters, and returns output. That's it.

Key Characteristics of Static Methods

• Called via ClassName::method() or self::method() within the class
• Can't access $this — the method has no object context
• Can access other static properties and methods using self:: or static::
• Shared across all instances (or rather, independent of any instance)
• Often used for utility functions, factory methods, and configuration helpers

Worth noting: PHP's static:: keyword (late static binding) behaves differently from self::. When you call self::method(), PHP resolves to the class where the method is defined. When you call static::method(), PHP resolves to the class that called the method at runtime. This distinction matters enormously in inheritance chains, and it's a source of bugs that trips up even experienced developers.

class ParentClass
{
    public static function create(): static
    {
        return new static(); // Late static binding — creates the calling class
    }
}

class ChildClass extends ParentClass {}

$child = ChildClass::create(); // Returns ChildClass, not ParentClass

What Are Instance Methods in PHP?

Instance methods belong to a specific object. You need to create an object with new before you can call them, and they have full access to $this — the object's internal state. PHP powers 71.7% of all websites with a known server-side language (W3Techs, March 2026), and the overwhelming majority of that code uses instance methods as its primary building block.

Here's the same concept, but as an instance method:

class PriceCalculator
{
    private float $taxRate;
    private string $currency;

    public function __construct(float $taxRate, string $currency = 'USD')
    {
        $this->taxRate = $taxRate;
        $this->currency = $currency;
    }

    public function calculateTotal(float $subtotal): float
    {
        return round($subtotal * (1 + $this->taxRate), 2);
    }

    public function format(float $amount): string
    {
        return $this->currency . ' ' . number_format($amount, 2);
    }
}

// Must create an object first
$calculator = new PriceCalculator(0.08, 'USD');
$total = $calculator->calculateTotal(99.99); // 107.99
echo $calculator->format($total); // USD 107.99

The calculateTotal method uses $this->taxRate — it depends on the state set during construction. Different objects carry different tax rates, so the same method call produces different results depending on which object you ask.

Key Characteristics of Instance Methods

• Called via $object->method()
• Full access to $this and all instance properties
• Each object can hold different state, producing different behavior
• The default in PHP OOP — most methods should be instance methods
• Can be mocked, swapped, and injected in tests

dependency injection in PHP

Static vs Instance Methods: Key Differences

Before you pick one, here's a side-by-side comparison that covers the eight dimensions that matter most in day-to-day PHP development.

The biggest practical difference isn't syntax or memory — it's testability. We'll get into exactly why in the testing section below.

Source: Author assessment based on PHP community best practices

When Should You Use Static Methods?

Static methods earn their place in specific situations. PHPStan adoption grew 9 percentage points year-over-year to 36% (JetBrains, 2026), and strict static analysis tools will flag unnecessary static methods. Here's when they're genuinely the right choice.

1. Pure Utility Functions

Functions that take input, return output, and touch nothing else. No state, no side effects, no dependencies.

class Str
{
    public static function slug(string $title, string $separator = '-'): string
    {
        $slug = preg_replace('/[^a-zA-Z0-9\s]/', '', $title);
        $slug = strtolower(trim($slug));
        return preg_replace('/\s+/', $separator, $slug);
    }

    public static function limit(string $value, int $limit = 100): string
    {
        if (mb_strlen($value) <= $limit) {
            return $value;
        }

        return mb_substr($value, 0, $limit) . '...';
    }
}

echo Str::slug('Static vs Instance Methods'); // static-vs-instance-methods

Laravel's Illuminate\Support\Str class follows this pattern. No object state needed, no reason to force new Str() on every call.

2. Factory Methods (Named Constructors)

When you need multiple ways to create an object, static factory methods communicate intent better than overloading the constructor.

class Money
{
    private function __construct(
        private int $cents,
        private string $currency
    ) {}

    public static function fromDollars(float $dollars, string $currency = 'USD'): static
    {
        return new static((int) round($dollars * 100), $currency);
    }

    public static function fromCents(int $cents, string $currency = 'USD'): static
    {
        return new static($cents, $currency);
    }

    public function add(Money $other): static
    {
        return new static($this->cents + $other->cents, $this->currency);
    }
}

$price = Money::fromDollars(29.99);  // Clear intent
$fee = Money::fromCents(500);        // Also clear

The constructor is private — you can only create objects through the named factory methods. This pattern is everywhere in modern PHP: Carbon dates, Laravel collections, and value objects.

3. Singleton Access Points

Configuration objects that should exist once in your application's lifecycle. Use sparingly — singletons are often a code smell.

class Config
{
    private static ?Config $instance = null;
    private array $data = [];

    private function __construct(array $data)
    {
        $this->data = $data;
    }

    public static function getInstance(): static
    {
        if (static::$instance === null) {
            static::$instance = new static(
                require __DIR__ . '/config.php'
            );
        }

        return static::$instance;
    }

    public function get(string $key, mixed $default = null): mixed
    {
        return $this->data[$key] ?? $default;
    }
}

When Should You Use Instance Methods?

Short answer: most of the time. Instance methods are the default in well-designed OOP code. The Stack Overflow Developer Survey 2026, with 49,000+ respondents across 177 countries, shows PHP used by 18.9% of developers, and the PHP community's frameworks overwhelmingly favor instance-based architecture (Stack Overflow, 2026).

1. When the Method Depends on Object State

If the method reads or writes instance properties, it must be an instance method. This isn't negotiable.

class ShoppingCart
{
    private array $items = [];

    public function addItem(string $name, float $price, int $quantity = 1): void
    {
        $this->items[] = [
            'name' => $name,
            'price' => $price,
            'quantity' => $quantity,
        ];
    }

    public function getTotal(): float
    {
        return array_reduce($this->items, function (float $carry, array $item) {
            return $carry + ($item['price'] * $item['quantity']);
        }, 0.0);
    }

    public function isEmpty(): bool
    {
        return count($this->items) === 0;
    }
}

$cart = new ShoppingCart();
$cart->addItem('PHP Book', 39.99);
$cart->addItem('Coffee', 4.50, 3);
echo $cart->getTotal(); // 53.49

Each ShoppingCart object holds its own items. The getTotal() calculation depends entirely on what's in $this->items.

2. When You Need Dependency Injection

This is where static methods completely fall apart. If your class needs a database connection, a logger, or an API client, instance methods let you inject those dependencies through the constructor.

class UserRepository
{
    public function __construct(
        private PDO $db,
        private LoggerInterface $logger
    ) {}

    public function findById(int $id): ?array
    {
        $stmt = $this->db->prepare('SELECT * FROM users WHERE id = ?');
        $stmt->execute([$id]);

        $user = $stmt->fetch(PDO::FETCH_ASSOC);

        $this->logger->info('User lookup', ['id' => $id, 'found' => $user !== false]);

        return $user ?: null;
    }
}

You can't do this with static methods. A static findById() would need to create its own database connection or pull it from a global — both are terrible ideas in production code.

3. When You Need Polymorphism

Instance methods work with interfaces. Static methods don't — at least not in any practical way that enables dependency injection and testing.

interface PaymentGateway
{
    public function charge(float $amount, string $token): PaymentResult;
}

class StripeGateway implements PaymentGateway
{
    public function __construct(private string $apiKey) {}

    public function charge(float $amount, string $token): PaymentResult
    {
        // Stripe API call using $this->apiKey
    }
}

class PayPalGateway implements PaymentGateway
{
    public function __construct(private string $clientId, private string $secret) {}

    public function charge(float $amount, string $token): PaymentResult
    {
        // PayPal API call
    }
}

Your payment processing code depends on PaymentGateway, not on Stripe or PayPal. Swapping implementations is a one-line configuration change in your service container. Try doing that with StripeGateway::charge().

PHP interfaces and contracts

How Do Static Methods Affect Testing?

This is the section that changes how junior developers think about static methods. PHPUnit sits at 50% adoption, but 32% of PHP developers write no tests at all (JetBrains, 2026). If you're in that 32%, understanding testability now saves you from painful rewrites later.

From experience: I've watched teams spend weeks refactoring static method calls out of codebases when they finally started writing tests. The original code worked fine — the static calls weren't buggy. But they made it impossible to test the classes that called them in isolation.

The Problem: You Can't Mock Static Calls

When class A calls B::doSomething(), there's no way to replace B with a test double in standard PHPUnit. The class name is hardcoded.

// Hard to test — static dependency is baked in
class OrderProcessor
{
    public function process(Order $order): void
    {
        // Can't replace this with a fake in tests
        $tax = TaxCalculator::calculate($order->getSubtotal(), $order->getState());
        $order->setTax($tax);

        // Can't replace this either
        EmailService::send($order->getCustomerEmail(), 'Order confirmed');
    }
}

To test OrderProcessor, you're forced to also test TaxCalculator and EmailService. You can't isolate the processing logic. If the email service fails in your test environment, your order processing tests fail too.

The Solution: Instance Methods + Dependency Injection

class OrderProcessor
{
    public function __construct(
        private TaxCalculatorInterface $taxCalculator,
        private EmailServiceInterface $emailService
    ) {}

    public function process(Order $order): void
    {
        $tax = $this->taxCalculator->calculate(
            $order->getSubtotal(),
            $order->getState()
        );
        $order->setTax($tax);

        $this->emailService->send($order->getCustomerEmail(), 'Order confirmed');
    }
}

Now your test can inject fakes:

class OrderProcessorTest extends TestCase
{
    public function testProcessCalculatesTaxAndSendsEmail(): void
    {
        $taxCalculator = $this->createMock(TaxCalculatorInterface::class);
        $taxCalculator->method('calculate')->willReturn(8.50);

        $emailService = $this->createMock(EmailServiceInterface::class);
        $emailService->expects($this->once())
            ->method('send')
            ->with('customer@example.com', 'Order confirmed');

        $processor = new OrderProcessor($taxCalculator, $emailService);
        $processor->process($order);
    }
}

Each dependency is isolated. The test runs in milliseconds, doesn't send real emails, and doesn't care about tax logic. That's the power of instance methods with dependency injection.

According to JetBrains, Pest adoption grew to 17% (up 4 percentage points year-over-year), while PHPStan reached 36% adoption (JetBrains, 2026). Both tools reward instance-based architecture — Pest makes test writing more expressive, and PHPStan can catch type errors in injected dependencies at analysis time.

Source: JetBrains State of PHP 2026 (1,720 developers, 194 countries)

PHPUnit testing

Do Static Methods Perform Better Than Instance Methods?

This is the question every junior developer asks — and the answer might surprise you. Kinsta's PHP benchmarks show WordPress on PHP 8.5 handles 148.30 req/s compared to 139.06 req/s on PHP 7.4 (Kinsta, 2026). But the performance gap between static and instance method calls? It's negligible.

Our finding: In synthetic benchmarks calling the same method 10 million times, static calls are roughly 5-10% faster because PHP skips the object context lookup. In real applications, this difference vanishes inside database queries, network calls, and file I/O that take orders of magnitude longer.

Here's a quick benchmark you can run yourself:

class BenchmarkStatic
{
    public static function compute(int $n): int
    {
        return $n * $n;
    }
}

class BenchmarkInstance
{
    public function compute(int $n): int
    {
        return $n * $n;
    }
}

// Static: ~0.35s for 10M calls
$start = microtime(true);
for ($i = 0; $i < 10_000_000; $i++) {
    BenchmarkStatic::compute($i);
}
$staticTime = microtime(true) - $start;

// Instance: ~0.38s for 10M calls
$obj = new BenchmarkInstance();
$start = microtime(true);
for ($i = 0; $i < 10_000_000; $i++) {
    $obj->compute($i);
}
$instanceTime = microtime(true) - $start;

echo "Static: {$staticTime}s\n";
echo "Instance: {$instanceTime}s\n";

The ~8% difference on 10 million calls amounts to 30 milliseconds. Your average database query takes 5-50ms alone. One API call takes 100-500ms. Don't choose static methods for performance — choose them when they're the right design tool.

Source: Kinsta PHP Benchmarks 2026

What Does Laravel Actually Do With Static and Instance Methods?

Laravel is the most popular PHP framework at 64% adoption (JetBrains, 2026). Understanding how Laravel uses both method types gives you a real-world mental model.

Facades: Static Syntax, Instance Reality

Laravel facades look like static calls but aren't. When you write Cache::get('key'), Laravel's facade system resolves an instance from the service container behind the scenes.

// This looks static...
Cache::get('user:1');

// But it actually does this:
app('cache')->get('user:1');

// Which resolves to an instance of Illuminate\Cache\CacheManager

Why? Because the team behind Laravel wanted the clean syntax of static calls with the testability of instance methods. You get both:

// In tests, you can fake the facade
Cache::shouldReceive('get')
    ->with('user:1')
    ->andReturn(['name' => 'Nishil']);

Key takeaway: Laravel facades prove that the PHP community values testability so much that they built an entire abstraction layer to get static-looking syntax without the testing drawbacks. If the largest PHP framework goes to that length to avoid real static calls, that tells you something about where the industry stands.

Eloquent: Instance Methods for State

Eloquent models are pure instance-method territory. Each model instance represents a database row with its own state.

$user = new User();
$user->name = 'Nishil';
$user->email = 'nishil@example.com';
$user->save(); // Instance method — saves THIS user's state

// Static-looking calls are actually query builder factories
$users = User::where('active', true)->get();
// Equivalent to: (new User)->newQuery()->where('active', true)->get()

Even User::where() uses __callStatic() to forward to an instance method on the query builder. It's instances all the way down.

Laravel Eloquent

Common Mistakes With Static Methods in PHP

After working with PHP codebases of all sizes, these are the patterns that cause the most pain — especially for teams that are growing and adding tests.

Mistake 1: Using Static Methods as Global State Holders

// Don't do this
class AppState
{
    private static array $data = [];

    public static function set(string $key, mixed $value): void
    {
        self::$data[$key] = $value;
    }

    public static function get(string $key): mixed
    {
        return self::$data[$key] ?? null;
    }
}

Static properties persist across requests in long-running processes (Swoole, RoadRunner, Laravel Octane). What worked in traditional PHP-FPM can cause data leaking between requests when you move to async runtimes.

Mistake 2: Static Methods That Hide Dependencies

// Hard to see what this class actually needs
class ReportGenerator
{
    public static function generate(int $reportId): string
    {
        $db = Database::getInstance();     // Hidden dependency
        $cache = Cache::getInstance();      // Hidden dependency
        $logger = Logger::getInstance();    // Hidden dependency

        // 200 lines of logic...
    }
}

Compare that to an instance-based version where the constructor declares exactly what's needed:

class ReportGenerator
{
    public function __construct(
        private PDO $db,
        private CacheInterface $cache,
        private LoggerInterface $logger
    ) {}

    public function generate(int $reportId): string
    {
        // Same logic, but dependencies are explicit
    }
}

Mistake 3: Making Everything Static "Because It's Easier"

This is the most common trap. You don't need an object right now, so you make the method static. Six months later, you need to add a dependency, and you're refactoring every call site.

The rule is simple: if you're unsure, use an instance method. You can always make an instance method static later (just remove $this usage). Going the other direction — static to instance — requires changing every caller.

A Decision Framework: Static or Instance?

When you're staring at a new method and wondering which way to go, walk through these questions in order.

1. Does this method read or write $this?
Yes → instance method. Full stop.

2. Does this method need any external dependency (database, API, file system, logger)?
Yes → instance method with dependency injection.

3. Is this a pure function with no side effects?
Yes → static method is fine. Think Str::slug(), Arr::flatten().

4. Is this a factory method creating instances of this class?
Yes → static method. Think Money::fromDollars(), Carbon::parse().

5. Will this method need to be mocked in tests?
Yes → instance method behind an interface.

6. Are you unsure?
Use an instance method. It's the safer default.

The one-way door principle: Converting an instance method to static is a one-line change (add static, remove $this). Converting a static method to instance requires changing every call site in your codebase. When in doubt, keep the door open — use instance methods.

PHP design patterns

Frequently Asked Questions

Can you call a static method on an instance in PHP?

Yes, PHP allows $object->staticMethod(), but don't do it. PHPStan (now at 36% adoption among PHP developers, per JetBrains, 2026) flags this as misleading. Use ClassName::staticMethod() for clarity. The instance syntax works but implies the method uses object state, which it doesn't.

Are PHP static methods thread-safe?

PHP traditionally runs in a share-nothing architecture (one process per request), so thread safety wasn't a concern. But with async runtimes like Swoole and Laravel Octane, static properties persist across requests. Static methods that read/write static properties can cause data leaks between users. The 58% of developers not planning to leave PHP (JetBrains, 2026) will increasingly face this as async adoption grows.

Do Laravel facades count as static methods?

No. Laravel facades use PHP's __callStatic() magic method to forward calls to an instance resolved from the service container. When you call Cache::get('key'), you're actually calling an instance method on a CacheManager object. This gives you static-like syntax with full testability — facades can be mocked with Cache::shouldReceive().

When should I use self:: vs static:: in PHP?

Use static:: when you want late static binding — meaning child classes should resolve to themselves, not the parent. Use self:: only when you explicitly want to reference the class where the code is defined. In most cases, static:: is the correct choice. Factory methods (static::create()) and singleton patterns (static::$instance) should always use static:: to support inheritance correctly.

Is there a performance benefit to static methods in PHP 8?

Technically yes — static calls skip the object context lookup, saving roughly 5-10% in synthetic benchmarks of 10 million iterations. In practice, this amounts to ~30ms over 10 million calls. WordPress on PHP 8.5 handles 148.30 req/s (Kinsta, 2026), and that throughput comes from PHP version upgrades, opcode caching, and JIT compilation — not from method type choices.

Conclusion

Static and instance methods aren't interchangeable tools that do the same thing differently. They solve different problems, and choosing the right one shapes how your code behaves, how it's tested, and how it evolves.

Here's what to remember:

• Static methods are for stateless utilities, factory methods, and class-level operations that don't need $this
• Instance methods are the default — use them whenever you have state, need dependencies, or want testability
• Performance differences are negligible in real applications — design for correctness, not micro-optimization
• Laravel's facades prove the industry values testability over static convenience
• The one-way door rule — instance-to-static is easy, static-to-instance is painful

With 89% of PHP developers on PHP 8.x and PHPStan adoption growing 9 points year-over-year, the ecosystem is moving toward stricter, more testable code. Start with instance methods as your default, reach for static only when the criteria are clearly met, and you won't need to refactor later.

next steps in PHP OOP

PHP Traits vs Abstract Classes vs Interfaces: When to Use Each

PHP 8.1 Enums: Backed Enums and Laravel Eloquent Casts

How Do You Secure an API? The 4-Layer Framework That Actually Works