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

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

نوشته شده توسط: علیرضا ارومند
۲۷ آذر ۱۳۹۷
زمان مطالعه: 8 دقیقه
۵
(۱)

مقدمه

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

“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 با مشخصات مورد نیاز را می‌سازد.
خوب در اینجا به پایان قسمت اول از این مجموعه می‌رسیم. سایر الگو‌ها را در قسمت‌های بعدی با هم بررسی خواهیم کرد.

چه رتبه ای می‌دهید؟

میانگین ۵ / ۵. از مجموع ۱

اولین نفر باش

title sign
معرفی نویسنده
علیرضا ارومند
مقالات
24 مقاله توسط این نویسنده
محصولات
42 دوره توسط این نویسنده
علیرضا ارومند

علیرضا ارومند به عنوان Product Manager شرکت داتین (وابسته به فناپ) در حوزه پروژه‌های بانکی فعال است.او همچنین مدرس و Technical Manager پروژه‌های نیک آموز می باشد از دیگر تخصص های او میتوان به: تولید فریمورک برنامه نویسی فوق العاده حرفه‌ای با مدیریت بیش از 1 میلیون تراکنش در ثانیه، همکاری با تیم توسعه شرکت ارتباط فردا (بانک آینده)، مشاور فنی شرکت توسعه رفاه پردیس (بانک رفاه)، مدیر فنی خبرگزاری نسیم، سخنران تنها همایش مورد تایید مایکروسافت در خاورمیانه در حوزه ASP.NET Core، مدیر فنی خبرگزاری بین المللی پیام‌کوتاه نسیم (برنده جشنواره وب ایران)، مدرس دوره های Dot Net ، ASP.NET در نیک آموز، همکاری با تیم توسعه شرکت ارتباط فردا

پروفایل نویسنده
title sign
دیدگاه کاربران

    • سلام
      ای کاش ادامه این آموزش رو هم قرارد بدید

    • سلام
      ای کاش ادامه این آموزش رو هم قرارد بدید

    • سلام
      بسیار عالی بود.
      بخش های بعدی منتشر نشده؟

    • سلام
      بسیار عالی بود.
      بخش های بعدی منتشر نشده؟

دانلود کتاب معماری میکروسرویس

همین الان نام و ایمیل را وارد کنید، کمتر از 30 ثانیه دانلود کنید.
دانلود رایگان کتاب میکروسرویس (PDF)
close-link
جشنواره عیدآموز نیک آموز، سال جدید رو با قدرت شروع کن
مشاهده تخفیف ها
close-image