الگوهای تخصیص مسئولیت در شی گرایی

مقدمه

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

“Understanding responsibilities is key to good object-oriented design.”

حالا که تعیین وظایف و مسئولیت‌ها اینقدر مهم هستند چطور می‌توانیم این کار رو به بهترین وجه انجام بدهیم؟ آیا فقط تجربه راهکار ما برای انجام این کار است یا مهندسی نرم افزار راهنمایی برای ما قرار داده است؟ خوب جواب طبق معمول همه اصول مهندسی معلومه. برای هر کاری که روتین است حتما اصول و روش‌هایی هم وجود داره و در این مورد خاص GRASPراهنمای ما است.

GRASP چیست؟

GRASPاز سر واژه‌های General Responsibility Assignment Software Patterns/Principles ساخته شده است. مجموعه اصول و قواعد و الگوهایی که به ما کمک می‌کنند در مورد تخصیص وظایف و مسئولیت‌ها درست تصمیم بگیریم. این الگو ها عبارتند از:

• Controller
• Creator
• High Cohesion
• Information Expert
• Low Coupling
• Polymorphism
• Protected Variations
• Pure Fabrication

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

الگوی Creator

یکی از ساده ترین الگوهای GRASP هست و جوابی به یک سوال عمومی. هنگام توسعه نرم افزار حتما بارها و بارها نیاز به ساخت یک شی از یک کلاس داشتید. اما سوال اساسی این است که چه کسی وظیفه ساخت نمونه از کلاس مورد نظر ما رو دارد؟ تخصیص درست این وظیفه می‌تواند باعث پایین آوردن وابستگی‌ها، بالا بردن وضوح طراحی و در نهایت بالابردن قابلیت استفاده مجدد از برنامه ما بشود..
خوب طبق تعریفی که آقای لارمن در این مورد دارند کلاس B وظیفه ساخت کلاس A را باید به عهده داشته باشد تنها اگر یکی از شرایط زیر وجود داشته باشد.

• کلاس B شامل کلاس A باشد. یا یک رابطه Aggregation با هم داشته باشن.
• کلاس B سوابق کلاس A را نگهداری کند.
• کلاس B استفاده بسیار زیادی از کلاس A داشته باشد
• کلاس B اطلاعاتی در اختیار داشته باشد که برای ساخته شدن کلاس A ضروری است

برای روشن تر شدن موضوع به تصویر زیر دقت کنید:
همانطور که در تصویر مشاهده می‌کنید هدف ما طراحی سیستم برای ثبت سفارش است. هر سفارش تعدادی خطوط سفارش دارد که جزئیات آن را نگهداری می‌کند. و هر خط سفارش شامل یک کالا است. حالا سوالی که مطرح می‌شود این است که در این سیستم مسئول ایجاد شی از جنس SalesLineItem کدام یک از کلاس‌های موجود در تصویر است؟ با توجه به رابطه‌ای که بین کلاس Sale و SalesLineItem وجود دارد و مد نظر قراردادن بایدها و نبایدهای الگوی Creator مسئولیت این کار به عهده کلاس Sale است.با توجه به مطالبی که گفته شد، همانطور که در نمودار بالا نحوه تحقق این موضوع را مشاهده می‌کنید. در هر جایی از برنامه نیاز به ساخته شدن SalesLineItem داشته باشیم، دستور MakeLineItem با تعداد کالایی که قرار است در ردیف سفارش قرار بگیرد برای Sale ارسال می‌شود و کلاس Sale نمونه ای از SalesLineItem با مشخصات مورد نیاز را می‌سازد.
خوب در اینجا به پایان قسمت اول از این مجموعه می‌رسیم. سایر الگو‌ها را در قسمت‌های بعدی با هم بررسی خواهیم کرد.