اصول Solid در یونیتی - قسمت اول (S)

بیایید هر مفهوم را بررسی کنیم و ببینیم چگونه به شما در ساخت کد قابل فهمتر، انعطاف‌پذیرتر و قابل نگهداری‌تر کمک می‌کنند:

اصل مسئولیت تک‌گانه (Single Responsibility Principle یا SRP) :

اصل مسئولیت تک‌گانه (SRP) این ایده را بیان می‌کند که هر کلاس باید فقط یک دلیل برای تغییر داشته باشد، به عبارت دیگر، هر کلاس باید مسئولیت تنها یک کار را داشته و فقط آن بخش از منطق را در خود شامل کند.

بهتر است پروژه‌های خود را از قطعه‌های کوچک‌تری تشکیل دهید و از ساختارهای یکپارچه بزرگ (monolithic) خودداری کنید. کلاس‌ها و توابع کوتاه‌تر، راحت‌تر درک می‌شوند و پیاده‌سازی می‌شوند.

احتمالاً اگر مدتی در Unity کار کرده باشید، با این مفهوم آشنایی دارید. هنگامی که یک GameObject ایجاد می‌کنید، از قطعات کوچکتری تشکیل شده است. به عنوان مثال، ممکن است شامل موارد زیر باشد:

• یک MeshFilter که یک ارجاع به مدل سه‌بعدی را نگهداری می‌کند
• یک Renderer که کنترل می‌کند چگونه سطح مدل در صفحه نمایش ظاهر می‌شود
• یک Transform که مقیاس، چرخش و موقعیت را نگهداری می‌کند
• یک Rigidbody اگر نیاز به تعامل با شبیه‌سازی فیزیکی داشته باشد

هر کامپوننت یک کار را انجام می‌دهد و آن را به خوبی انجام می‌دهد. شما یک صحنه کامل را با استفاده از GameObjectها ساخته‌اید. تعامل بین کامپوننت‌های آن‌ها است که بازی را ممکن می‌سازد.

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

اگر اصل مسئولیت تک‌گانه را نادیده بگیرید، ممکن است یک کامپوننت سفارشی ایجاد کنید که این کار را انجام می‌دهد:

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

1. کلاس PlayerAudio : این کلاس مسئول پخش صداها در هنگام برخورد بازیکن با چیزی است.

2. کلاس PlayerInput : این کلاس مسئول مدیریت ورودی‌ها برای بازیکن است.

3. کلاس PlayerMovement : این کلاس مسئول کنترل حرکت بازیکن است.

با تقسیم کلاس Player به این کلاس‌های مختلف، هر کلاس فقط مسئولیت خاص خود را دارد و این به شما کمک می‌کند تا کد راحت‌تر قابل نگهداری، تغییر و توسعه باشد.

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

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

هنگام کار با اصل مسئولیت تک‌گانه، این اهداف را در نظر داشته باشید:

- خوانایی: کلاس‌های کوتاهتر راحت‌تر قابل خواندن هستند. قاعده دقیقی وجود ندارد، اما بسیاری از توسعه‌دهندگان حدود ۲۰۰-۳۰۰ خط را به عنوان محدوده‌ای کوتاه معرفی می‌کنند. برای خودتان یا به عنوان تیم، تعیین کنید که چه مقدار به عنوان "کوتاه" در نظر گرفته می‌شود. وقتی این حد را بگذرانید، تصمیم بگیرید که آیا می‌توانید آن را به بخش‌های کوچک‌تری تقسیم کنید یا خیر.

- قابلیت گسترش: از کلاس‌های کوچکتر به راحتی می‌توانید ارث‌بری کنید. آن‌ها را به سادگی تغییر داده یا جایگزین کنید .

- قابل استفاده مجدد: کلاس‌های خود را به صورت کوچک و ماژولار طراحی کنید تا بتوانید از آن‌ها در بخش‌های دیگر بازی خود استفاده کنید.

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

صحبت پایانی این بخش :

سادگی اغلب در طراحی نرم‌افزار مورد بحث قرار می‌گیرد و یک پیشنیاز برای قابلیت اعتماد است. آیا می‌توانید برنامه خود را به مرور زمان گسترش دهید و آن را حفظ کنید؟ .با رعایت کردن اصول Solid ، کد شما قابلیت مقیاس‌پذیری، انعطاف‌پذیری و قابلیت خوانایی بیشتری دارد. با این حال، این الگوها و اصول نیاز به کار اضافی و برنامه‌ریزی دارند. "ساده" برابر با "ساده" نیست.

قسمت بعد به دومین اصل طراحی Solid که Open-closed principle نام دارد خواهیم پرداخت

امیر فاطمی - Amir Fatemi