روی خط زندگی

گشت و گذار من در هنر نرم افزار

روی خط زندگی

گشت و گذار من در هنر نرم افزار

۲ مطلب در دی ۱۳۹۳ ثبت شده است

GRASP مخفف General Responsibility Assignment Software Pattern است که همان طور که از نامش پیداست، به مبحث تعیین و توزیع مسئولیت ها بین موجودیت ها می پردازد. مانند اینکه چه کسی وظیفه تولید این اطلاعات را دارد، یا چه کسی مسئولیت نگه داری از اطلاعات را دارد، یا چه کسی باید پیام های ارسالی سیستم را مدیریت کند و مانند آن.


GRASP از نه عدد الگو تشکیل شده است. این نه الگو به ما کمک می کنند تا مسئولیت هر موجودیت در سیستم را تعیین کنیم:

1) Creator

چه کسی مسئول ایجاد یک شی است؟ برای یافتن فردی که این مسئولیت را به وی بدهیم سوالات زیر را می پرسیم:

  • آیا موجودیت این شی، موجودیت شی یا اشیای دیگری را هم ایجاب می کند؟ (همان رابطه Composition در نمودار کلاس ها)
  • آیا کلاسی هست که اطلاعات لازم برای تولید این شی را داشته باشد؟

2) Controller

هیچگاه مستقیما یک عنصر مرتبط با رابط کاربری (UI) را مستقیما به Business Class متصل نکنید (این امر یکی از دلایل افزایش Coupling می باشد). بهتر است یک کلاس Controller در بین آنها قرار دهیم که این دو با واسطه کلاس Controller به هم متصل شوند. الگوی MVC یکی از بهترین نمونه ها برای این مطلب است.


3) Pure Fabrication

اگر دیدید که یک مسئولیت قواره تن هیچ یک از کلاس های موجود نیست، بهتر آن است که یک کلاس جدید بسازیم و مسئولیت را به آن کلاس دهیم، چرا که در صورتی که مسئولیت مورد نظر را به یکی از کلاس های موجود بدهیم، در واقع Cohesion را کاهش داده ایم.


4) Information Expert

مسئولیت را به کسی (کلاسی) بدهیم که اطلاعات لازم برای انجام آن کار را در اختیار دارد.


5) High Cohesion

شاید اگر برای این یکی مثال عکس بزنم راحت تر بتوان توضیح داد، فرض کنید که یک کلاس داریم با تعداد بالایی از Property  ها و Method ها، که این Property ها و Method ها هیچ کاری با هم ندارند و هر کدام برای خودشان کار خود را انجام می دهند. این یعنی Low Cohesion که ناقض اصول طراحی شی گرا، مانند اصل تک مسئولیت ای (Single Responsibility) و God Object Code Smell است.


6) Indirection

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


7) Low Coupling

یعنی ارتباطات بین موجودیت ها را به نحوی کاهش دهیم که کمترین وابستگی را به یکدیگر داشته باشند. این بدان معنی نیست که موجودیت ها نباید هیچ وابستگی به هم داشته باشند، بلکه باید این وابستگی ها را تا حد ممکن کاهش داد.


8) Polymorphism

هر موجودیت، رفتار خودش را با توجه به نوع خود ، به صورت خودکار تعیین و اصلاح کند!


9) Protected Variation

ذات سیستم ها تغییر است. مهم نیست حجم تغییرات چه میزان ست، بلکه مهم آن است که سیستم را در برابر تغییرات ایمن سازی کنیم. اگر اصولی مانند وراثت، یا Open Close Principle (OCP) را رعایت کنیم، می توانیم تغییرات را در سیستم مدیریت کنیم.


۰ نظر موافقین ۱ مخالفین ۰ ۲۸ دی ۹۳ ، ۲۰:۴۳
حسین گویا

Code Smell ها علائم سطحی ای هستند که حاکی از وجود مشکلات عمیق در سیستم می باشند. (مارتین فولر)

این تعریف جناب فولر، بیان عمیق و درستی از مفهوم Code Smell ها ارائه می دهد. وقتی در یک سیستم نشانه هایی از Code Smell ها مشاهده می کنیم می توانیم حدس بزنیم که این سیستم احتمالا در جایی به مشکل خواهد خورد و یا توسعه و پشتیبانی آن دچار اشکال خواهد بود. Code Smell ها نشانه هایی از زلزله ای قریب الوقوع در سیستم می باشند. به برخی از مهمترین Code Smell ها به اختصار اشاره می کنیم:


  • Duplicated code: کد های تکراری در برنامه که ناقض اصل DRY هستند.
  • Long Method: وجود متد های طولانی در سیستم علاوه بر نقض اصول OOP بخصوص اصل تک مسئولیتی (Single Responsibility) ، پیگیری خطاها را مشکل خواهد کرد.
  • Large Class یا God Object: اصل تک مسئولیتی را نقض می کنند و به مانند متد های طولانی رهگیری خطاها را دشوار می سازند. همچنین عموما این کلاس ها سبب ایجاد درهم تنیدگی (Coupling) در سیستم می شوند.

  • Feature envy: استفاده بیش از حد یک کلاس از کلاس دیگر. این مورد شاید توضیح بیشتری لازم داشته باشد. فرض کنید یک کلاس برای مدیریت نمرات دانش آموزان داریم. حال می خواهیم معدل دانش آموزان را حساب کنیم. برای این کار می توانیم تک تک نمرات دانش آموز را از کلاس بگیریم و معدل وی را در خارج از کلاس دانش آموز محاسبه کنیم، اما این یک مشکل بزرگ ایجاد می کند. ما (به عنوان یک کلاس دیگر) بیش از حد به کلاس دانش آموز وابسته شده ایم و با هر تغییری در لیست نمرات کد های کلاس ما نیز دچار مشکل می شود. بهتر آن است که این وظیفه را به خود کلاس دانش آموز بدهیم و در واقع کلاس دانش آموز یک تابع ارائه نماید که معدل دانش آموزان را حاسبه کرده و نتیجه را در اختیار ما قرار می دهد. به بیان دیگر، یک کلاس باید در ارائه خصوصیات به دنیای بیرون خساست به خرج دهد و فقط چیز هایی را به بیرون ارائه دهد که لازم است.

۰ نظر موافقین ۱ مخالفین ۰ ۱۸ دی ۹۳ ، ۲۲:۲۹
حسین گویا