10 اصل برنامه نویسی شی گرا که هر برنامه نویسی باید درباره آن بداند

اغلب اوقات با توسعه دهندگانی ملاقات می کنم که در مورد اصول SOLID نشنیده اند (ما در اینجا به تفصیل در مورد آنها صحبت کرد.. - ترجمه) یا برنامه نویسی شی گرا (OOP)، یا شنیده می شود، اما در عمل از آنها استفاده نکنید. این مقاله مزایای اصول OOP را شرح می دهد که به توسعه دهنده در کار روزانه خود کمک می کند. برخی از آنها به خوبی شناخته شده هستند، برخی دیگر نه چندان زیاد، بنابراین این مقاله هم برای مبتدیان و هم برای برنامه نویسان با تجربه مفید خواهد بود.

یادآوری می کنیم: برای همه خوانندگان "Habr" - تخفیف 10 روبل هنگام ثبت نام در هر دوره Skillbox با استفاده از کد تبلیغاتی "Habr".

Skillbox توصیه می کند: دوره آموزشی آنلاین "توسعه دهنده جاوا".

خشک (خودت را تکرار نکن)

یک اصل نسبتاً ساده که جوهر آن از نام آن مشخص است: "خودت را تکرار نکن". برای یک برنامه نویس، این به معنای نیاز به اجتناب از کدهای تکراری و همچنین توانایی استفاده از انتزاع در کار است.

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

این به منظور ساده سازی کد و سهولت در نگهداری آن ضروری است که وظیفه اصلی OOP است. شما نیز نباید از اتحادیه سوء استفاده کنید، زیرا همان کد با OrderId و SSN بررسی نمی شود.

کپسولاسیون را تغییر دهید

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

اگر در جاوا می نویسید پس به طور پیش فرض خصوصی را به متدها و متغیرها اختصاص دهید.

اصل باز بودن / نزدیکی

این اصل را می توان با خواندن عبارت زیر به راحتی به خاطر آورد: "موجودات نرم افزار (کلاس ها، ماژول ها، توابع و غیره) باید برای توسعه باز باشند، اما برای اصلاح بسته باشند." در عمل، این بدان معنی است که آنها می توانند اجازه دهند رفتار خود بدون تغییر کد منبع تغییر کند.

این اصل زمانی مهم است که تغییرات در کد منبع نیاز به بازبینی، آزمایش واحد و سایر رویه‌ها داشته باشد. کدی که از اصل باز/بسته پیروی می کند با گسترش تغییر نمی کند، بنابراین مشکلات بسیار کمتری در آن وجود دارد.

در اینجا یک مثال از کدی است که این اصل را نقض می کند.

اگر نیاز به تغییر چیزی در آن داشته باشید، زمان زیادی می برد، زیرا باید تمام قسمت هایی از کد را که با قطعه مورد نظر ارتباط دارند، تغییر دهید.

به هر حال، باز بودن-بسته بودن یکی از اصول SOLID است.

اصل مسئولیت واحد (SRP)

اصل دیگری از مجموعه SOLID. می گوید که "تنها یک دلیل وجود دارد که منجر به تغییر طبقه می شود." کلاس فقط یک وظیفه دارد. ممکن است چندین روش داشته باشد، اما هر یک از آنها فقط برای حل یک مشکل مشترک استفاده می شود. همه روش‌ها و ویژگی‌ها باید فقط در خدمت این باشند.

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

اصل وارونگی وابستگی (DIP)

مورد بالا یک مثال کد است که در آن AppManager به EventLogWriter وابسته است که به نوبه خود ارتباط نزدیکی با AppManager دارد. اگر به روش دیگری برای نمایش اعلان نیاز دارید، چه فشار، پیامک یا ایمیل، باید کلاس AppManager را تغییر دهید.

مشکل را می توان با DIP حل کرد. بنابراین، به جای AppManager، یک EventLogWriter درخواست می کنیم که با استفاده از فریم ورک تزریق می شود.

DIP با تغییر ماژول وابستگی این امکان را فراهم می کند که به راحتی ماژول های فردی را با دیگران جایگزین کنید. این امکان تغییر یک ماژول را بدون تأثیرگذاری بر ماژول های دیگر ممکن می کند.

ترکیب به جای ارث

دو راه اصلی برای استفاده مجدد از کد، وراثت و ترکیب هستند که هر کدام مزایا و معایب خاص خود را دارند. معمولاً دومی ترجیح داده می شود زیرا انعطاف پذیرتر است.

Composition به شما این امکان را می دهد که رفتار یک کلاس را در زمان اجرا با تنظیم ویژگی های آن تغییر دهید. هنگام پیاده‌سازی رابط‌ها، از چند شکلی استفاده می‌شود که اجرای انعطاف‌پذیرتری را به همراه دارد.

حتی "جاوای موثر" جاشوا بلوخ توصیه می کند که ترکیب را به ارث بری ترجیح دهیم.

اصل تعویض باربارا لیسکوف (LSP)

اصل دیگری از جعبه ابزار SOLID. بیان می کند که زیرگروه ها باید برای یک سوپرتایپ قابل تعویض باشند. یعنی متدها و توابعی که با یک سوپرکلاس کار می کنند باید بتوانند بدون مشکل با زیر کلاس های آن کار کنند.

LSP هم به اصل مسئولیت واحد و هم به اصل تفکیک مسئولیت مربوط می شود. اگر یک کلاس عملکرد بیشتری نسبت به یک زیر کلاس ارائه دهد، آنگاه کلاس دوم برخی از عملکردها را پشتیبانی نمی کند و این اصل را نقض می کند.

در اینجا یک قطعه کد است که با LSP در تضاد است.

روش area (Rectangle r) مساحت یک مستطیل را محاسبه می کند. این برنامه پس از اجرای Square از کار می افتد، زیرا Square در اینجا یک مستطیل نیست. طبق اصل LSP، توابعی که از ارجاع به کلاس های پایه استفاده می کنند باید بتوانند از اشیاء کلاس های مشتق شده بدون دستورالعمل اضافی استفاده کنند.

این اصل، که تعریف خاصی از یک نوع فرعی است، توسط باربارا لیسکوف در کنفرانسی در سال 1987 به نام "انتزاع داده ها و سلسله مراتب" ارائه شد - از این رو نام آن است.

اصل جداسازی رابط (ISP)

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

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

از آنجایی که نوشتن یک رابط کار پیچیده ای است، پس از اتمام کار، تغییر آن بدون شکستن چیزی مشکل ساز خواهد شد.

مزیت اصل ISP در جاوا این است که همه متدها باید ابتدا پیاده سازی شوند و تنها پس از آن می توانند توسط کلاس ها استفاده شوند. بنابراین، اصل امکان کاهش تعداد روش ها را فراهم می کند.

برنامه نویسی برای یک رابط، نه یک پیاده سازی

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

شما باید از نوع رابط برای متغیرها، انواع برگشتی یا نوع آرگومان متد استفاده کنید. یک مثال استفاده از SuperClass به جای SubClass است.

به این معنا که:

لیست اعداد= getNumbers();

اما نه:

اعداد ArrayList = getNumbers();

در اینجا یک پیاده سازی عملی از آنچه در بالا گفته شد است.

اصل تفویض اختیار

یک مثال رایج متدهای ()quals و hashCode() در جاوا است. هنگامی که دو شیء نیاز به مقایسه دارند، این عمل به جای کلاس کلاینت به کلاس مناسب واگذار می شود.

مزیت اصل این است که کد تکراری وجود ندارد و تغییر رفتار نسبتا آسان است. همچنین در مورد نمایندگی رویداد اعمال می شود.

همه این اصول به شما امکان می دهد کدهای انعطاف پذیرتر، زیباتر و قابل اعتمادتر با انسجام بالا و کوپلینگ کم بنویسید. البته، تئوری خوب است، اما برای اینکه یک توسعه دهنده واقعاً شروع به استفاده از دانش به دست آمده کند، تمرین لازم است. قدم بعدی پس از تسلط بر اصول OOP می تواند مطالعه الگوهای طراحی برای حل مشکلات رایج توسعه نرم افزار باشد.

Skillbox توصیه می کند:

• دوره عملی "موبایل توسعه دهنده PRO".
• دوره آنلاین کاربردی "تحلیلگر داده پایتون".
• دوره عملی دو ساله "من یک توسعه دهنده وب PRO هستم".

منبع: www.habr.com