این مقاله درباره یکی از تجربیاتی است که من در هنگام ساخت چارچوبی(Framework) با زبان سی شارپ در موتور بازی سازی یونیتی به اون رسیدم. البته این تجربه به صورت مستقیم ربطی به یونیتی نداره و صرفا درباره یک الگوی طراحی(Design Pattern) در زبانی شی گرا است.
در واقع این چارچوب ساخته شد تا کنترل بهتری بر روی روند اجرا شدن کد ها داشته باشم با وجود اینکه این چارچوب کارهای زیادی انجام میداد ولی واسط بسیار ساده ای داشت.
این واسط از دو تابع Register و Unregister تشکیل شده بود که نمونه ای از کلاس ها را در چارچوب ثبت و یا حذف می کرد. اما از اونجایی که کارهای زیادی انجام میداد تعداد خط های کد این کلاس به چیزی نزدیک به هزار خط رسیده بود که اصلا خوب نبود و نگهداریش رو سخت می کرد.
همونطور که همگی اطلاع داریم یکی از ویژگی های یک کلاس خوب رعایت نمودن اصل تک مسئولیتی است(Single Responsibility Principle)، مشخصا کلاس چارچوب در حال رعایت نمودن این اصل نبود چون کار های زیادی رو انجام میداد ولی با این حال از دو تابع بیشتر تشکیل نشده بود پس نمیشد اون رو به چندین کلاس عمومی(Public) تقسیم کرد تا هر کدوم از این کلاس ها یکی از وظایف رو به عهده بگیرند و یکی از کارها رو انجام بدن چون همه کارها کاملا درون چارچوب رخ میداد.
من به کلاسی احتیاج داشتم که عمومی نباشه و همچنین به عناصر خصوصی کلاس چارچوب نیز دسترسی داشته باشه تا مجبور نباشم برای دسترسی به اطلاعات چارچوب اون ها رو به صورت عمومی تعریف کنم (اصل Encapsulation) و همینطور قابلیت این رو داشته باشه که توی یک فایل دیگر قابل تعریف باشه.
خوشبختانه سی شارپ همه چیز هایی که من احتیاج داشتم رو داشت.
این دو قابلیت سی شارپ با هم پتانسیل بسیار زیادی برای اعمال Encapsulation و اصل تک مسئولیتی دارن، مخصوصا در شرایطی که من باهاش مواجه بودم.
ابتدا کلاس چارچوب رو به صورت Partial تعریف کردم این کار باعث میشد کلاس های دیگه که به صورت تو در تو قرار بود تعریف بشن در فایل های جداگانه قرار بگیرند و نه این که همگی در فایل کلاس چارچوب قرار بگیرند که خودش باعث میشد که فایل کلاس چارچوب خیلی شلوغ بشه.
بعدش کلاس های دیگه که قرار بود وظایف چارچوب رو انجام بدن رو به صورت تو در تو و همچنین به صورت خصوصی(Private) در فایل های جداگانه تعریف کردم.
این کار باعث می شد که فایل کد های منبع نظم بهتری داشته باشند و همچنین این کلاس ها در خارج از کلاس چارچوب در دسترس نباشند یعنی دنیای بیرون خبری از این کلاس های نداشت انگار این کلاس ها اصلا وجود ندارند که از دیدگاه Encapsulation عالی هستش.
بعد از انجام تمامی این کارها کلاس چارچوب از هزار خط کد به چیزی کمتر از 300 خط کد رسید که از دیدگاه نگهداری خیلی بهتر بود و نزدیک به ده کلاس به وجود اومد که تک تک وظایف چارچوب رو انجام می دادند.
الان دیگه اگه می خواستم مثلا در یکی از ویژگی های چارچوب تغییر ایجاد کنم لازم نبود که کل کلاس چارچوب رو تغییر بدم میرفتم مستقیم اون کلاسی که مسئول انجام اون کار بود تغییر میداد که بعدها خیلی به درک تغییر که داده بودم کمک می کرد و خوانایی کد رو افزایش میداد.
از دیدگاه من این روش یک الگوی طراحی(Design Pattern) هستش که من قبلا بهش بر نخورده بودم و تو شرایطی که بهتون توضیح دادم خوانایی و نگهداری کد رو به صورت فوق العاده ای افزایش داد.
اگه میخواین کدی با قابلیت نگهداری و خوانایی بیشتر تولید کنید در هنگام نوشتن کد این الگو رو هم مد نظر قرار بدید.
