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

In software engineering, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable.

wikipedia

 

1-Single Responsibility Principle

اصل اول میگه هر کلاس باید مسئول انجام یک کار خاص باشه.
رعایت این اصل چه مزیتی داره؟
کلاس ها کوتاه تر میشن و دیگه کد تکراری نداریم
(DRY: Do not Repeat Yourself)

2-Open/Closed Principle

اصل دوم به این موضوع اشاره داره که کلاس ها قابل توسعه باشن(باز) و غیرقابل تغییر دادن (بسته)
فرض کنید که کارخونه ماشین سازی برای ماشینی که ساخته میخواد لاستیک انتخاب کنه.
وقتی لاستیک رو انتخاب و برای ماشین استفاده میکنه دیگه حق نداره روی لاسیتک تغییراتی ایجاد کنه.
مثلا بیاد عاج و طرح روی لاسیتک رو تغییر بده
اگر لاسیتک برای ماشین مناسب نیست باید از یک نوع دیگه استفاده کنه

تو این مثال انواع لاستیک رو میشه به عنوان کلاس های بسته(Closed) در نظر گرفت

یه مثال دیگه :
دستگاه باد مکانیکی
شاید تو مکانیکی دیده باشید که از این دستگاه برای باد زدن چرخ ها و چرخش مته(دریل) و کارهای دیگه استفاده میشه

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

3-Liskov Substitution Principle

وقتی به جای کلاس parent از کلاس extend شده‌اش (یعنی child) استفاده کنیم نباید تو برنامه مشکلی پیش بیاد.
به عنوان مثال وقتی خروجی متدهای کلاس والد ، آرایه است و ما تو کلاس فرزند ،تایپ خروجی متدها رو تغییر بدیم دیگه نمیتونیم از این کلاس فزرند تو جایی که کلاس والد استفاده شده استفاده کنیم چون تایپ خروجی فرق میکنه و برنامه دچار مشکل میشه.

4-Interface Segregation Principle

تو کلاس ها نباید متدهای اضافی وجود داشته باشه و از اینترفیس درستی باید متدها رو پیاده سازی کنن.
مثال: شارژرهای چند پین رو در نظر بگیرید که میتونه دستگاه های مختلفی رو شارژر کنه.
وقتی روی هر دستگاه همچین شارژری (چند تبدیل) داده بشه عملا بقیه حالت های اون شارژر بلا استفاده هستن.
برای همین برای هر دستگاهی(موبایل و لپ تاپ) شارژر مخصوص به خودش رو میدن نه همچین شارژری که چندین مدل تبدیل داشته باشه.
همه این ها میتونن مبدل شارژر باشن که بشه به برق وصل کرد ولی باید متناسب با هر دستگاه شارژر مخصوص به خودش داده بشه.

5-Dependency Inversion

اصل آخر که ممکنه با Dependency Injection اشتباه گرفته بشه.
تعریف این اصل:
کلاس‌های سطح بالا نباید به کلاس‌های سطح پایین وابسته باشن؛ هر دو باید وابسته به انتزاع باشن. موارد انتزاعی نباید وابسته به جزییات باشن ،جزییات باید وابسته به انتزاع باشن. (خیلی گنگه!)

کلاس سطح پایین کارهایی رو انجام میده که کلی و پایه ای هستن.مثل ارتباط با دیتابیس

کلاس سطح بالا کارهای جزئی تر و خاص تر رو انجام میده که برای انجام دادنشون نیاز به کلاس سطح پایین داره.مثل کلاسی که وظیفه گرفتن لیستی از فاکتورها رو داره که برای اینکار باید از کلاس دیتابیس(که کلاس سطح پایینه) استفاده کنه.

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

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

برای دستگاه های برقی این مهمه که پریزها و دوشاخه مناسب هم باشن یعنی دوشاخه وابسته به پریز(مفهوم) هست، نه نوع سیمی که به پریز وصل شده.(جزئیات)