به عنوان برنامه‌نویس، همیشه دنبال نوشتن کد تمیز، قابل نگهداری و قابل گسترش هستیم. اصول SOLID یک سری راهنما برای رسیدن به این هدف‌ها ارائه می‌ده.
- مفهوم: هر کلاس باید فقط یک دلیل برای تغییر داشته باشه و یک مسولیت رو بپذیره!
- مثال: فکر کن یه دستگاه قهوه‌ساز داری که هم قهوه درست می‌کنه و هم رادیو داره. اگه رادیو خراب بشه، ممکنه نتونی قهوه درست کنی تا رادیو تعمیر بشه. بهتره دستگاه‌های جدا برای قهوه و موسیقی داشته باشی.
- مفهوم: موجودیت‌های نرم‌افزاری باید برای گسترش باز و برای تغییر بسته باشن.
- مثال: فرض کن یک فروشگاه آنلاین داری که روش‌های مختلف پرداخت رو پشتیبانی می‌کنه. به جای اینکه هر بار که یک روش پرداخت جدید اضافه می‌کنی، کد اصلی فروشگاه رو تغییر بدی، می‌تونی یک ساختار ماژولار طراحی کنی که هر روش پرداخت به صورت یک ماژول جداگانه باشه. اینجوری، وقتی می‌خوای یک روش پرداخت جدید مثل پرداخت با بیت‌کوین اضافه کنی، فقط کافیه یک ماژول جدید برای اون روش پرداخت بسازی و به سیستم اضافه کنی، بدون اینکه کد اصلی فروشگاه تغییر کنه.
جایگزینی لیسکوف یا اصل جایگزین‌پذیری Liskov مفهومی در برنامه‌نویسی شیءگرا است که تضمین می‌کند هر شیء یا نمونه‌ای از یک کلاس می‌تواند به جای هر نمونه دیگری از آن کلاس قرار گیرد بدون اینکه عملکرد برنامه‌ی کامل را تحت تاثیر قرار دهد. به این معنی که اگر یک کلاس زیرکلاس (subclass) باشد، باید بتواند به جای کلاس اصلی (SuperClass) قرار گیرد و همه‌ی عملکردها به درستی کار کنند.
فرض کنید که شما یک کلاس اتومبیل (Car) دارید که دارای عملکردهایی مانند شروع کردن (start)، توقف کردن (stop) و حرکت کردن (move) است. حالا شما یک زیرکلاس به نام اتومبیل الکتریکی (ElectricCar) ایجاد می‌کنید که همه‌ی این عملکردها را به ارث می‌برد.
بر اساس اصل جایگزین‌پذیری لیسکوف، اگر برنامه شما برای کلاس اتومبیل نوشته شده باشد، باید بتوانید به جای هر اتومبیل، یک اتومبیل الکتریکی قرار دهید و برنامه همچنان به درستی کار کند، به این معنی که توابع start، stop و move به درستی اجرا شوند بدون نیاز به تغییر در کد برنامه.
- مفهوم: هیچ مشتری نباید مجبور باشه به متدهایی که استفاده نمی‌کنه وابسته باشه.
- مثال: فکر کن یه ابزار چندکاره داری با قابلیت‌های جدا برای کارهای مختلف (پیچ‌گوشتی، چاقو، درب‌بازکن). هر ابزار وظیفه خاصی داره بدون اینکه مجبور باشی امکانات اضافی رو حمل و استفاده کنی.
- مفهوم: ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشن. هر دو باید به انتزاع وابسته باشن.
یک مثال ساده از اعمال اصل DIP می‌تواند در استفاده از وابستگی‌ها و تزریق وابستگی باشد. به عنوان مثال، فرض کنید شما یک برنامه‌ای دارید که برای ارسال ایمیل به کاربران خود نیاز به استفاده از یک سرویس ایمیل دارد. به جای اینکه مستقیماً به یک سرویس خاص مثل Gmail یا Outlook وابسته شوید، شما یک رابط یا اینترفیس برای سرویس ارسال ایمیل خود تعریف می‌کنید.
