اصول SOLID چیست و چرا بدون آن‌ها کدها پیر می‌شوند؟

SOLID مجموعه‌ای از پنج اصل طراحی در برنامه‌نویسی شیءگراست که هدف آن‌ها «زیبا کردن کد» نیست، بلکه کمک به ساخت نرم‌افزاری است که بتواند در برابر تغییر دوام بیاورد. بسیاری از پروژه‌ها در ابتدا خوب کار می‌کنند، اما بعد از چند ماه توسعه، هر تغییر کوچکی باعث ایجاد باگ‌های زنجیره‌ای می‌شود. SOLID دقیقاً برای جلوگیری از همین فرسودگی تدریجی به‌وجود آمده است.

برخلاف تصور رایج، SOLID مجموعه‌ای از قوانین خشک نیست. این اصول در واقع خلاصه‌ی تجربه‌ی سال‌ها شکست و موفقیت در پروژه‌های واقعی هستند. وقتی این اصول رعایت نمی‌شوند، کد معمولاً «کار می‌کند» اما قابل اعتماد، قابل توسعه و قابل فهم نیست. وقتی رعایت می‌شوند، سیستم حتی با بزرگ شدن هم قابل کنترل باقی می‌ماند.

اصل اول: مسئولیت واحد (Single Responsibility Principle)

این اصل می‌گوید هر کلاس باید فقط یک دلیل برای تغییر داشته باشد. خیلی‌ها این جمله را حفظ کرده‌اند، اما معنایش را درست نفهمیده‌اند. مسئولیت واحد یعنی یک کلاس فقط یک نقش مشخص در سیستم داشته باشد، نه اینکه همه‌چیز را با هم انجام دهد. وقتی یک کلاس هم منطق تجاری را مدیریت می‌کند، هم لاگ می‌نویسد و هم با دیتابیس کار می‌کند، در واقع چند مسئولیت متفاوت را با هم قاطی کرده است.

مثال ساده‌ی دنیای واقعی: تصور کن یک نفر هم راننده باشد، هم حسابدار، هم تعمیرکار و هم مدیر شرکت. شاید در ابتدا شدنی باشد، اما به‌محض بزرگ شدن کار، همه‌چیز به‌هم می‌ریزد. در کد هم دقیقاً همین اتفاق می‌افتد. کلاس‌هایی که چند مسئولیت دارند، زودتر از همه به نقطه‌ای می‌رسند که دیگر کسی جرئت دست زدن به آن‌ها را ندارد.

اصل دوم: باز-بسته (Open/Closed Principle)

این اصل می‌گوید موجودیت‌های نرم‌افزاری باید برای توسعه باز باشند، اما برای تغییر بسته. یعنی بتوانیم رفتار جدید اضافه کنیم، بدون اینکه کد قبلی را خراب یا دستکاری کنیم. این اصل مستقیماً با آینده‌ی پروژه در ارتباط است، چون تغییر همیشه اتفاق می‌افتد؛ سؤال این است که آیا سیستم تو برای تغییر آماده است یا نه.

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

اصل سوم: جایگزینی لیسکوف (Liskov Substitution Principle)

این اصل می‌گوید اگر یک کلاس فرزند جای کلاس والد استفاده شود، نباید رفتار سیستم خراب شود. یعنی فرزند باید واقعاً قابل جایگزینی با والد باشد، نه فقط از نظر اسم و ارث‌بری، بلکه از نظر رفتار منطقی. این اصل جلوی ارث‌بری‌های اشتباه و فریب‌دهنده را می‌گیرد.

مثال ساده: اگر بگویی «پرنده» می‌تواند پرواز کند، بعد کلاسی به نام «پنگوئن» از آن ارث‌بری کند، سیستم به مشکل می‌خورد. چون پنگوئن پرنده است، اما پرواز نمی‌کند. این دقیقاً نقض LSP است. در کد هم اگر یک کلاس فرزند نتواند همان انتظاری را که از والد می‌رود برآورده کند، یعنی طراحی اشتباه بوده است.

اصل چهارم: تفکیک رابط‌ها (Interface Segregation Principle)

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

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

اصل پنجم: وارونگی وابستگی‌ها (Dependency Inversion Principle)

این اصل می‌گوید ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند؛ هر دو باید به انتزاع وابسته باشند. به زبان ساده‌تر، منطق اصلی سیستم نباید درگیر جزئیات پیاده‌سازی شود. این اصل پایه‌ی اصلی Dependency Injection است و بدون آن، سیستم به‌شدت شکننده می‌شود.

فرض کن منطق اصلی برنامه مستقیماً به دیتابیس، فایل سیستم یا سرویس خارجی وصل باشد. در این حالت، هر تغییر کوچک در جزئیات، کل سیستم را تحت تأثیر قرار می‌دهد. اما اگر منطق فقط با «قرارداد» کار کند و جزئیات قابل تعویض باشند، سیستم انعطاف‌پذیر، تست‌پذیر و قابل توسعه می‌شود.

چرا SOLID فقط برای پروژه‌های بزرگ نیست؟

خیلی‌ها فکر می‌کنند SOLID مخصوص سیستم‌های عظیم است، اما واقعیت برعکس است. اگر از پروژه‌های کوچک شروع به رعایت این اصول نکنی، وقتی پروژه بزرگ شد دیگر اصلاح آن تقریباً غیرممکن می‌شود. SOLID مثل کمربند ایمنی است؛ شاید در مسیر کوتاه به‌نظر بی‌اهمیت بیاید، اما وقتی تصادف شد، نبودش فاجعه است.

حتی در پروژه‌های شخصی یا تمرینی، رعایت حداقلی SOLID باعث می‌شود ذهنت به‌صورت مهندسی رشد کند. کم‌کم یاد می‌گیری قبل از نوشتن کد، به نقش‌ها، وابستگی‌ها و تغییرات آینده فکر کنی. این همان چیزی است که برنامه‌نویس را از کدنویس جدا می‌کند.

جمع‌بندی نهایی

SOLID قرار نیست کد را پیچیده کند؛ قرار است پیچیدگی را کنترل‌پذیر کند. این اصول به تو کمک می‌کنند سیستمی بسازی که تغییر، دشمن آن نباشد. وقتی SOLID را عمیق بفهمی، دیگر دنبال حفظ کردن تعریف‌ها نیستی؛ خودت هنگام طراحی، به‌صورت طبیعی به این اصول می‌رسی.