SOLID قوانین سالید به زبان ساده

سالید به زبان ساده
SOLID
سالید مخفف پنج اصل مهم در مدیریت وابستگی ها است

اصل اول:
Single Responsibility Principle
به این معنی که هر کلاس فقط باید یک کار انجام دهد و نه بیشتر
مثال : در کلاس ارسال ایمیل فقط باید متدهای ارسال ایمیل پیاده سازی شود و نه بیشتر، اگر در این کلاس از متدهای ارسال اس ام اس استفاده شود این قانون نقض میشود


Open-Closed Principle
هر کلاس باید قابل توسعه و غیر قابل تغییر باشد
مثال : کلاسی داریم که ارسال ایمیل با سرور جیمیل را انجام میدهد که تعدادی ورودی و یک خروجی استرینگ دارد
حال اگر بخواهیم ارسال ایمیل با سرور یاهو را هم به پروژه اضافه کنیم دو راه داریم یکی اینکه در متد قبلی یک ورودی برای سرور اضافه کنیم و یک شرط ایف در بدنه متد قراردهیم برای چک کردن ، که این عملیات اصل دو سالید را نقض میکند
راه دوم و صحیح افزودن یک متد دیگر برای ارسال با یاهو


Liskov Substitution Principle
هر کلاسی که از کلاس دیگر ارث بری میکند هرگز نباید رفتار کلاس والد را تغییر دهد

مثال: این مورد رو با یک مثال کاملا قابل فهم بیان میکنم
در ریاضیات مربع همان مستطیل است
طبق این اصل ما میتوانیم کلاسی به نام مستطیل ایجاد کنیم که طول و عرض را به عنوان ورودی میگیرد و مستطیل را در خروجی بر میگرداند
کلاس دیگری داریم به نام مربع که این کلاس از کلاس مستطیل مشتق شده
کلاس را نمونه سازی میکنیم به شکل زیر
Rectangle rstngl=new Squre();

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

Interface Segregation Principle
این اصل به این موضوع اشاره دارد که چند اینترفیس کوچک شده بهتر از یک اینترفیس است
مثال: همان طور که میدانید یک کلاس میتواند متدهای چندین اینترفیس را ایمپلمنت یا همان پیاده سازی کند
فرض کنید اینترفیسی داریم که حاوی ده متد است و یک کلاس داریم که از این اینترفیس ارث بری میکند و فقط به یکی از این متدها نیاز دارد
بنابراین نه متد دیگر بلا استفاده هستند ولی باید حتما بدنه آنها در کلاس فرزند ساخته شود
برای رفع این مشکل میتوانیم اینترفیس را به دو اینترفیس مجزا که یکی داری نه متد و دیگری یک متد است تبدیل کنیم و هر کجا به هر ده متد نیاز داشتیم کلاس از هر دو اینترفیس ارث بری کند

Dependency Inversion Principle
اصل معکوس سازی وابستگی
مثال: اوایل که موبایل تازه داشت رونق میگرفت یک سری تولید کننده شارژر وجود داشتند که هر بار که یک موبایل روانه بازار می شد مجبور بودن طراحیشون رو بر طبق این مدل موبایل تغییر بدن و کار به جایی رسید که یک سیم شارژی تولید شد که بیش از ده خروجی داشت برای همه موبایل ها
اما این راه حل صحیح نبود !!!
بنابراین شرکت های تولید شارژر تصمیم گرفتند اعتصاب کنند که به جای اینکه چیزی که شما میخواین رو ما تولید کنیم
چیزی که ما میخوایم رو شماها تولید کنید
اتفاقا شرکت های موبایلی هم از این طرح استقبال کردن و یک استاندارد بینشون رد و بدل شد
بنابراین وابستگی وارونه شد !!!
در کلاس ها هم دقیقا مشابه این اتفاق بارها برای همه پیش اومده
راه حل :اول استفاده از اینترفیس ها به جای کلاس های سطح بالا
دوم عدم اشاره به جزئیات در اینترفیس ها