اصول SOLID چین دقیقا ⁉️

درواقع SOLID یه سری اصول مهم توی برنامه‌نویسی شیءگراست هستش که کمک میکنه کدهای تمیز، قابل تغییر و کم‌اشکال بنویسیم.

➊ اصل مسئولیت واحد

Single Responsibility Principle

هر کلاس فقط باید یک کار انجام بده.

✅ چرا ؟ اگه یه کلاس چند کار مختلف انجام بده، تغییر توی یک بخش ممکنه بقیه قسمت‌ها رو هم خراب کنه.

🎯 مثال: فرض کن یه کلاس داریم که هم سفارش ثبت می‌کنه، هم فاکتور صادر می‌کنه، هم ایمیل ارسال می‌کنه! اگه فقط بخش ایمیل نیاز به تغییر داشته باشه، ممکنه کل سیستم بهم بریزه. بهتره هر کار رو به کلاس مخصوص خودش بسپاریم.

➋ اصل باز/بسته

OCP - Open/Closed Principle‌ ‌‌ ‌ ‌ ‌‌ ‌ ‌

کد باید برای تغییر بسته، ولی برای توسعه باز باشه.

✅ چرا؟ اگه مجبور باشیم برای اضافه کردن یه قابلیت، کدهای قدیمی رو تغییر بدیم، ممکنه یه جای دیگه خراب بشه.

🎯 مثال: فرض کن یه کلاس داریم که تخفیف رو روی فاکتور اعمال می‌کنه. اگه بخوایم یه نوع جدید تخفیف اضافه کنیم، نباید توی کلاس قبلی دست ببریم. به‌جاش یه کلاس جدید برای نوع جدید تخفیف می‌سازیم که به سیستم اضافه بشه، بدون اینکه چیزی خراب بشه.

➌ اصل جایگزینی لیسکوف

LSP - Liskov Substitution Principle

کلاس‌های فرزند باید بدون مشکل جایگزین کلاس والد بشن.

✅ چرا؟ اگه یه کلاس فرزند به‌درستی جای والد خودش رو نگیره، برنامه رفتار غیرمنتظره‌ای پیدا می‌کنه.

🎯 مثال: فرض کن یه سیستم پرداخت داریم که روش‌های مختلفی مثل کارت بانکی و کیف پول رو پشتیبانی می‌کنه. اگه یه متد "پرداخت()" توی والد باشه، همه کلاس‌های فرزند باید بتونن درست ازش استفاده کنن. حالا اگه یه روش پرداخت مثل "پرداخت با امتیاز" اضافه کنیم که امکان پرداخت نصفه‌نیمه داره، کل سیستم ممکنه به مشکل بخوره!

➍ اصل تفکیک اینترفیس‌ها

ISP - Interface Segregation Principle

اینترفیس‌ها نباید متدهای اضافی داشته باشن.

✅ چرا؟ اگه یه کلاس مجبور بشه متدهایی رو پیاده‌سازی کنه که بهش نیاز نداره، کد به‌هم‌ریخته و پیچیده می‌شه.

🎯 مثال:
فرض کن یه اینترفیس داریم به اسم Device که متدهای پرینت، اسکن و فکس داره. حالا یه کلاس داریم برای یه پرینتر ساده که فقط پرینت می‌کنه، ولی مجبور می‌شه متدهای اسکن و فکس رو هم پیاده‌سازی کنه، در حالی که بهشون نیازی نداره. بهتره اینترفیس رو به چند بخش جدا تقسیم کنیم.

➎ اصل وارونگی وابستگی

DIP - Dependency Inversion Principle

ماژول‌های اصلی نباید مستقیم به جزئیات وابسته باشن، بلکه به اینترفیس‌ها وابسته باشن.

✅ چرا؟ اگه یه بخش از سیستم وابسته به یه کلاس خاص باشه، هر تغییری توی اون کلاس می‌تونه باعث خرابی کل سیستم بشه.

🎯 مثال: فرض کن یه سیستم گزارش‌گیری داریم که داده‌ها رو از یه دیتابیس خاص مثل MySQL می‌گیره. اگه یه روز بخوایم به PostgreSQL یا MongoDB مهاجرت کنیم، کل کدهای گزارش‌گیری باید تغییر کنن. ولی اگه وابستگی‌ها به یه اینترفیس Database باشه، می‌تونیم دیتابیس رو عوض کنیم، بدون اینکه به کدهای اصلی دست بزنیم.

#WhatsThat #SOLID

𝗖𝗛𝗔𝗡𝗡𝗘𝗟  |  𝗚𝗥𝗢𝗨𝗣

➖➖➖➖➖➖➖➖➖