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

سالید مخفف پنج اصل مهم در مدیریت وابستگی ها استاصل اول:Single Responsibility Principleبه این معنی که هر کلاس فقط باید یک کار انجام دهد و نه بیشترمثال : در کلاس ارسال ایمیل فقط باید متدهای ارسال ایمیل پیاده سازی شود و نه بیشتر، اگر در این کلاس از متدهای ارسال اس ام اس استفاده شود این قانون نقض میشودOpen-Closed Principleهر کلاس باید قابل توسعه و غیر قابل تغییر باشدمثال : کلاسی داریم که ارسال ایمیل با سرور جیمیل را انجام میدهد که تعدادی ورودی و یک خروجی استرینگ داردحال اگر بخواهیم ارسال ایمیل با سرور یاهو را هم به پروژه اضافه کنیم ۳ راه داریم :یکی اینکه در متد قبلی یک ورودی برای سرور اضافه کنیم و یک شرط ایف در بدنه متد قراردهیم برای چک کردن ، که این عملیات اصل دو سالید را نقض میکندراه دوم افزودن یک متد دیگر برای ارسال با یاهو است که باز هم اصل دوم نقض می شودو راه سوم این است که یک کلاس پدر برای ارسال ایمیل داشته باشیم و به ازای هر سرور ایمیل یک کلاس و متد به پروژه اضافه کنیم،اینگونه اصل دوم را نقض نکرده ایم و برای اضافه کردن مثلا یاهو کافی است یک کلاس به برای یاهو با متد ارسال ایمیل که از پدر میگیرد و پیاده سازی میکند اضافه کنیم و اینگونه اصل دوم حفظ می شود.Liskov Substitution Principleهر کلاسی که از کلاس دیگر ارث بری میکند هرگز نباید رفتار کلاس والد را تغییر دهدمثال: این مورد رو با یک مثال کاملا قابل فهم بیان میکنمدر ریاضیات مربع همان مستطیل استطبق این اصل ما میتوانیم کلاسی به نام مستطیل ایجاد کنیم که طول و عرض را به عنوان ورودی میگیرد و مستطیل را در خروجی بر میگرداندکلاس دیگری داریم به نام مربع که این کلاس از کلاس مستطیل مشتق شدهکلاس را نمونه سازی میکنیم به شکل زیرRectangle rstngl=new Squre();حال وقتی متد مستطیل این متغیر را فراخوانی میکنیم و ورودی ها را ست میکنیم خروجی ما یک مربع است در حالی که کلاس والد خروجی اش باید یک مستطیل باشد، این خروجی در ریاضیات صحیح اما در برنامه نویسی غلط است چراکه کلاس فرزند در رفتار کلاس والد تغییر ایجاد کرد و خروجی آن را به مربع تبدیل کردبرای حل این موضوع باید از اینترفیس ها به جای کلاس والد استفاده کردInterface Segregation Principleاین اصل به این موضوع اشاره دارد که چند اینترفیس کوچک شده بهتر از یک اینترفیس استمثال: همان طور که میدانید یک کلاس میتواند متدهای چندین اینترفیس را ایمپلمنت یا همان پیاده سازی کندفرض کنید اینترفیسی داریم که حاوی ده متد است و یک کلاس داریم که از این اینترفیس ارث بری میکند و فقط به یکی از این متدها نیاز داردبنابراین نه متد دیگر بلا استفاده هستند ولی باید حتما بدنه آنها در کلاس فرزند ساخته شودبرای رفع این مشکل میتوانیم اینترفیس را به دو اینترفیس مجزا که یکی داری نه متد و دیگری یک متد است تبدیل کنیم و هر کجا به هر ده متد نیاز داشتیم کلاس از هر دو اینترفیس ارث بری کندDependency Inversion Principleاصل معکوس سازی وابستگیمثال: اوایل که موبایل تازه داشت رونق میگرفت یک سری تولید کننده شارژر وجود داشتند که هر بار که یک موبایل روانه بازار می شد مجبور بودن طراحیشون رو بر طبق این مدل موبایل تغییر بدن و کار به جایی رسید که یک سیم شارژی تولید شد که بیش از ده خروجی داشت برای همه موبایل هااما این راه حل صحیح نبود !!!بنابراین شرکت های تولید شارژر تصمیم گرفتند اعتصاب کنند که به جای اینکه چیزی که شما میخواین رو ما تولید کنیمچیزی که ما میخوایم رو شماها تولید کنیداتفاقا شرکت های موبایلی هم از این طرح استقبال کردن و یک استاندارد بینشون رد و بدل شدبنابراین وابستگی وارونه شد !!!در کلاس ها هم دقیقا مشابه این اتفاق بارها برای همه پیش اومدهراه حل :اول استفاده از اینترفیس ها به جای کلاس های سطح بالادوم عدم اشاره به جزئیات در اینترفیس ها