چرا استفاده بیش از حد از static یک آنتی‌پترن است؟

استفاده بی‌رویه از متدها و پراپرتی‌های static در برنامه‌نویسی شیءگرا، به‌ویژه در PHP، یک آنتی‌پترن شناخته‌شده است که با نام‌هایی چون "Static Cling" یا "Global State" نیز از آن یاد می‌شود. اگرچه static در نگاه اول راحت به نظر می‌رسد، اما مشکلات معماری عمیقی ایجاد می‌کند که اصول نرم‌افزار قوی، مقیاس‌پذیر و قابل نگهداری را تضعیف می‌کند.

این مستند توضیح می‌دهد که چرا باید از static اجتناب کرد و چه زمانی استفاده از آن توجیه‌پذیر است.

مشکلات اصلی static

۱. چالش‌های تست‌پذیری

کدی که به شدت به static وابسته است، به سختی تست می‌شود.

• وابستگی‌های پنهان: وقتی یک متد استاتیک مانند Cache::get('key') را فراخوانی می‌کنید، یک وابستگی پنهان به کلاس Cache ایجاد می‌کنید. این وابستگی در امضای متد یا سازنده کلاس مشخص نیست و به شما اجازه نمی‌دهد آن را با یک Mock یا Stub در تست‌ها جایگزین کنید.

• آلودگی وضعیت سراسری (Global State): پراپرتی‌های استاتیک یک وضعیت سراسری ایجاد می‌کنند که در کل چرخه حیات برنامه به اشتراک گذاشته می‌شود. یک تست می‌تواند این وضعیت را تغییر دهد و باعث شود تست‌های بعدی به شکلی غیرقابل‌پیش‌بینی با شکست مواجه شوند. این موضوع منجر به تست‌های شکننده و ناپایدار می‌شود.

• نقض اصل تک‌مسئولیتی (SRP): متدهای استاتیک اغلب به محلی برای انباشت توابعی تبدیل می‌شوند که فراتر از مسئولیت یک کلاس واحد هستند و باعث نقض SRP می‌شوند.

۲. پیوند قوی (Tight Coupling)

فراخوانی‌های static یک ارتباط سخت و مستقیم بین کامپوننت‌ها ایجاد کرده و سیستم را غیرمنعطف می‌سازد.

• وابستگی مستقیم و سخت: فراخوانی ClassName::staticMethod() یک وابستگی سخت به ClassName ایجاد می‌کند. شما نمی‌توانید به راحتی این پیاده‌سازی را با دیگری جایگزین کنید، که این نقض مستقیم اصل باز/بسته (OCP) است.

• کابوس Refactoring: اگر بخواهید یک متد استاتیک را تغییر نام دهید، باید تمام فراخوانی‌های آن را در کل پروژه پیدا کرده و به‌روزرسانی کنید. این کار خسته‌کننده و مستعد خطا است.

۳. نقض اصول بنیادین OOP

static مفاهیم اساسی شیءگرایی را دور می‌زند و قدرت این پارادایم را محدود می‌کند.

• نبود چندریختی (Polymorphism): متدهای استاتیک به کلاس تعلق دارند، نه به یک نمونه از آن. بنابراین، نمی‌توان آن‌ها را در کلاس‌های فرزند بازنویسی (Override) کرد. این موضوع امکان استفاده از چندریختی را که یکی از پایه‌های طراحی انعطاف‌پذیر است، از بین می‌برد.

• نداشتن وضعیت نمونه (Instance State): متدهای استاتیک روی وضعیت یک نمونه از شیء ($this) عمل نمی‌کنند. این شما را از قدرت کپسوله‌سازی، یعنی بسته‌بندی داده و رفتار در یک شیء واحد، محروم می‌کند.

۴. مشکلات مقیاس‌پذیری و نگهداری

با رشد پروژه، راحتی اولیه static جای خود را به چالش‌های جدی نگهداری می‌دهد.

• کد اسپاگتی: وابستگی‌های پنهان، دنبال کردن جریان اجرای برنامه را دشوار کرده و به کد اسپاگتی منجر می‌شود.

• پیچیدگی دیباگ: وقتی یک پراپرتی استاتیک سراسری مقدار نادرستی دارد، تشخیص اینکه کدام بخش از کد و در چه زمانی آن را تغییر داده، بسیار دشوار است.

هشدار حیاتی: Race Condition در محیط‌های مدرن

در محیط‌های مدرن PHP مانند Laravel Octane یا Swoole، برنامه یک بار بوت شده و برای پاسخ به درخواست‌های همزمان در حافظه باقی می‌ماند.

استفاده از پراپرتی‌های استاتیک (مانند private static $handler;) در این شرایط یک آنتی‌پترن حیاتی و نقطه شکست واحد (Single Point of Failure) است.

از آنجایی که پراپرتی‌های استاتیک بین تمام درخواست‌ها به اشتراک گذاشته می‌شوند، وقوع Race Condition حتمی است. اگر دو درخواست همزمان تلاش کنند از کلاسی با پراپرتی استاتیک استفاده کنند، وضعیت یکدیگر را بازنویسی خواهند کرد. این امر منجر به نتایج فاجعه‌بار و غیرقابل‌پیش‌بینی می‌شود، از جمله:

• داده‌های خراب‌شده
• اطلاعات کش نادرست
• خطاهای مرگبار

چنین طراحی باید فوراً حذف و با یک سرویس عادی (غیر استاتیک) که از طریق تزریق وابستگی (Dependency Injection) مدیریت می‌شود، جایگزین گردد.

چه زمانی استفاده از static مجاز است؟

استفاده از static باید نادر و همیشه با توجیه قوی باشد. در اینجا چند سناریو که ممکن است قابل‌قبول باشد، آمده است:

توابع کمکی بدون وضعیت

متدهایی که هیچ وضعیت داخلی ندارند و عملیات خالص و قطعی انجام می‌دهند، می‌توانند static باشند. آن‌ها ورودی می‌گیرند، خروجی برمی‌گردانند و به هیچ وضعیت داخلی یا سراسری وابسته نیستند.

مثال‌ها:

• توابع کار با رشته یا آرایه.
• محاسبات ریاضی.
• ابزارهای قالب‌بندی تاریخ/زمان.

final class StringUtils {
    public static function truncate(string $text, int $length): string {
        // ... پیاده‌سازی
    }
}

بهترین روش

حتی برای توابع کمکی، قرار دادن آن‌ها در یک سرویس و تزریق آن (مانند StringFormatterInterface) تست‌پذیری بهتری فراهم کرده و با اصل وارونگی وابستگی سازگار است.

متدهای Factory

متدهای استاتیک می‌توانند به عنوان Factory برای ساخت اشیاء، به‌ویژه زمانی که منطق ساخت پیچیده است، استفاده شوند. این کار ساخت شیء را خواناتر می‌کند.

class User {
    // ...

    public static function createFromPayload(array $payload): self {
        if (empty($payload['email'])) {
            throw new InvalidArgumentException('ایمیل الزامی است.');
        }
        return new self($payload['name'], $payload['email']);
    }
}

$user = User::createFromPayload($request->all());

توجه

برای سناریوهای پیچیده‌تر، یک کلاس Factory اختصاصی و قابل تزریق یا الگوی Builder رویکردی برتر و انعطاف‌پذیرتر است.

سینگلتون‌ها (با احتیاط فراوان)

الگوی Singleton تضمین می‌کند که تنها یک نمونه از یک کلاس در کل برنامه وجود داشته باشد. این الگو اغلب با یک متد استاتیک getInstance() پیاده‌سازی می‌شود.

class DatabaseConnection {
    private static ?PDO $instance = null;

    public static function getInstance(): PDO {
        if (self::$instance === null) {
            self::$instance = new PDO(/* ... */);
        }
        return self::$instance;
    }
}

اخطار

سینگلتون‌ها اغلب یک آنتی‌پترن در نظر گرفته می‌شوند زیرا شکلی از وضعیت سراسری هستند. آن‌ها پیوند قوی ایجاد کرده و تست را دشوار می‌کنند. با احتیاط فراوان از آن‌ها استفاده کنید و در هر کجا که ممکن است، تزریق وابستگی را ترجیح دهید.

نتیجه‌گیری

اگرچه static کاربردهای خود را دارد، استفاده بیش از حد از آن نشانه واضحی از زوال معماری است. با ترجیح دادن تزریق وابستگی و سرویس‌های مبتنی بر نمونه، سیستمی می‌سازید که در بلندمدت تست‌پذیرتر، انعطاف‌پذیرتر و قابل نگهداری‌تر است. همیشه اشیاء و تزریق وابستگی را به متدهای استاتیک و وضعیت سراسری ترجیح دهید.