قواعد SOLID در طراحی شی‌گرا

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

عکس از whereiskieran.com

 

SRP یا قاعده‌ی تک‌وظیفه‌ای (Single responsibility principle)

There should never be more than one reason for a class to change

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

 

OCP یا قاعده‌ی باز-بسته (Open/closed principle)

Classes & functions should be open for extension but closed for modification

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

برای مثال فرض کنید می‌خواهیم برنامه‌ای بنویسیم که مساحت اشکال هندسی را محاسبه کند. بدیهی است که مساحت هر شکل با فرمول (و متد) متفاوتی محاسبه می‌شود. برای نوشتن این برنامه ابتدا برای هر شکل هندسی کلاس مخصوص خودش را ایجاد کرده و برای هرکدام از آن کلاس‌ها متد محاسبه‌ی مساحت متناسب با شکل (با نام فرضی CalculateArea) می‌نویسیم. سپس اینترفیسی به نام IShape ایجاد کرده که تضمین کند کلاس‌های اشکال هندسی این متد را پیاده‌سازی کرده‌اند و اینترفیس را به کلاس‌ها نسبت می‌دهیم.

در نهایت در کد اصلی (متد Main) داده‌های جدیدی از دیتا تایپ اینترفیس ایجاد کرده و شکل‌های هندسی مدنظر را به آن‌ها نسبت می‌دهیم (سطرهای ۹ و ۱۲). نوع داده‌ی IShape تضمین می‌کند که این اشیا دارای متد CalculateArea هستند. بنابراین امکان صدا زدن این متد (فارغ از نوع شکل هندسی) در سطرهای ۱۰ و ۱۳ وجود دارد.

به این طریق هنگام اضافه کردن یک شکل جدید به برنامه، نیازی به تغییر کدهای قبلی نیست و تنها با نسبت دادن اینترفیس IShape به کلاس آن می‌توان بدون دانستن نوع شکل در سایر نقاط برنامه مساحت آن را به دست آورد.

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

برگه‌ها : 1 2