علیرضا حسینی زاده
یه برنامه نویس
مدیر فنی افرافایل
درباره من
آموزش SOLID یا اصول شی گرایی به زبان ساده ارسال شده در ۲۲ بهمن ۱۳۹۷
بیایم یکم درباره اصول صحبت کنیم و وقتی اسم از اصول شی گرایی به میون میاد اولین چیزی که گفته میشه SOLID یا ۵ قانون اصل اصلی شی گراییه، مهم نیست توی چه زبانی و چه فریم ورکی کار میکنید، هر زبانی که شی گرایی داشته باشه میتونید این قوانین رو داخلش استفاده کنید تا کار توسعه و رشد اون نرم افزار شما در آینده بسیار راحت باشه.
اصولی کد زدن خیلی مهمه و فرق یک برنامه نویس تازه کار و حرفه ای رو همین رعایت اصول کدنویسی مشخص میکنه، توی شرکت هم همیشه به بچه ها میگم کدی که مینویسید اینکه کار کنه اصلا کافی نیست و باید کدتون بهینه با کامنت دقیق و اصولی نوشته شده باشه، اینه که مهمه
SOLID در اصل مخفف ۵ کلمه و اصل هست که میاد نحوه ساخت و توسعه کلاس ها و متدها و مدل وابستگی اونها رو مشخص میکنه تا وقتی از این کلاس ها و متد ها بخوایم شی بسازیم و در اپلیکیشنمون استفاده کنیم راحت تر و بهینه تر انجام بشه.
SOLID مخفف ۵ اصل زیره:
– Single Responsibility Principle
– Open/Closed Principle
– Liskov Substitution Principle
– Interface Segregation Principle
– Dependency Inversion Principle
نمیخوام زیاد توضیح بدم و میخوام در خلاصه ترین حالت ممکن و به زبان ساده اینا رو توضیح بدم و همینجا هم میگم که بسیار بسیار ساده هستن و اصلا چیز خاصی نیستن حتی شاید شما قبلا استفاده کرده باشید و خودتون نمیدونستید.
بریم برای توضیح
Single Responsibility Principle
این اصل یه چیز ساده میگه و اونم اینه که هر کلاس فقط باید یک کار رو انجام بده نه بیشتر، مثلا میگه نیاین یه کلاس بسازید به اسم CustomClass و هرچی دم دستتون اومد بریزین داخلش مثلا ارسال کامنت، ایجاد کاربر جدید، محاسبه قیمت قابل پرداخت سفارشات و…
میگه شما باید هر بخش رو به صورت کلاس های جداگانه تعریف کنید تا اگر بخواین توسعه بدین کار رو نیاز نباشه وارد کدهای بخش های بی ارتباط به موضوع بشین
حتی شما کل متدهای بخش سفارشات رو هم نباید یکجا بزارید، یعنی متدهای ساخت ایجاد و ویرایش و حذف سفارشات رو توی یک کلاس بزار، متدهای محاسبه تخفیفات و قیمت و تایید و رد سفارشات رو یک کلاس و متدهای نمایش سفارشات رو یک کلاس دیگه و… اینطوری شما هر بخشی رو بخواین توسعه بدین میرین همون کلاس رو توسعه میدید. حالا برای اینکه کار بهتر باشه میتونید پوشه ای به اسم سفارشات درست کنید و کلاس های مربوطه رو داخلش بزارید.
Open-Closed Principle
این اصل خیلی مهمه و به طور خلاصه میگه که کلاس های شما برای توسعه در آینده باید برای توسعه باز باشن و برای ویرایش بسته، یعنی اینکه اگر خواستید در آينده بخشی به نرم افزارتون اضافه کنید نیاز نباشه کلاس های قدیمی و اصلی سیستم رو تغییر بدید و با اضافه شدن یک کلاس جدید تمام کار توسعه انجام بشه.
Liskov Substitution Principle
به ساده ترین شکل ممکن یعنی هروقت از کلاسی ارث بری کردید و یک کلاس فرزند ساختید به هیچ عنوان رفتار متدهای کلاس پدر رو توی کلاس فرزند overwrite یا بازنویسی نکنید و تغییر بدید. به طور کلی اصل میگه همیشه متدهای داخل کلاس فرزند باید همون رفتاری رو نشون بدن که توی کلاس پدر دارن. همین
مثال سادش اینه اگه تو کلاس پدر متد store داریم توی کلاس فرزند اونو overwrite کردی داخلش مثلا آپدیت نکن و همون رفتار رو فقط باید انجام بدی دقیقا
Interface Segregation Principle
بازم بسیار ساده میگه اینترفیسی نسازید که داخلش متدی باشه که توی یکی از کلاس هایی که implement میکنید استفاده نشه. یعنی به طور کلی یک اینترفیس کلی مثلا برای کلاس کاربرانتون نسازید که تمام متدها داخلش باشه به جاش مثلا ۵ اینترفیس برای بخش ها و متدهای مختلف کلاس های کاربران بسازید، یعنی اینترفیس هاتون رو تا جایی که میشه تیکه تیکه و جدا کنید تا متدی داخلشون نباشه که جایی استفاده نشه.
Dependency Inversion Principle
اینم آخرین اصل که بازم سادست. به طور خلاصه میگه از اینترفیس استفاده کن به جای اینکه شی از کلاس های کوچیک تر داخل کلاس های اصلیت بسازی، میگه که هیچوقت نباید داخل کلاس اصلیمون وابستگی (شی ساختن) از کلاس های کوچکتر دیگر وجود داشته باشه.
همین به همین سادگی اصول SOLID رو یاد گرفتید.
اصل سوم رو اشتباه نوشتید.
Liskov Substitution Principle نمی گه متدهای پدر رو تو فرند override نکنید! بلکه می گه اگر تو کلاس پدر متدی داری باید دقیقا بتونی همون متد رو تو کلاس فرزند هم ازش بدرستی استفاده کنی طوری که اگر کلاس فرزند رو به جای پدر خواستی استفاده کنی مشکلی پیش نیاد.
مثلا فرض کن یه کلاس داری که داره که توش یه متد add داره و اومدی یه کلاس دومی که من اسمش رو می زاریم List ساختی که داره از کلاس CollectionBase ارث بری می کنه و می یای داخل کلاس List متد add رو می نویسی که یه چیزی رو به لیست اضافه کنه. تا اینجا درسته ولی حالا فرض کن که یه کلاس دیگه ساختی به اسم Array و اونهم از کلاس CollectionBase ارث بری می کنه و متد Add هم داخلشه ولی مسئله اینجاست که شما تو زبان برنامه نویسی نمی تونی به یه array چیزی رو اضافه کنی و ارایه های قابلیت این رو ندارن که بعد از ساخت چیزی بهشون اضافه بشه (البته راهکاریی هست که فعلا باهاش کاری نداریم!)
پس اگر ابجکت کلاس CollectionBase رو برداری و به جاش List رو بزاری همچنان پروژه کار می کنه ولی اگر از کلاس Array استفاده کنی خطا می ده.
راهکارش هم اینه که اون متدهایی که قابلیت پیاده سازی تو تمام فرزندها نیستند رو تو یه کلاس یا اینترفیس جدا قرار بدی و فقط فرزندهایی که قابلیت پیاده سازی اون متد رو دارند ازش ارث بری کنند که در اینجا فقط کلاس List ما می تونه از اینترفیس مورد نظر استفاده کنه.
درسته ممنون منظور منم همین بوده درست توضیح ندادم
با سلام، درسته ولی مثالت خوب نیست
ممنون