الگوی طراحی Factory

  • شماره مطلب : 2
  • دسته بندی : الگو های طراحی نرم افزار
  • عنوان : الگوی طراحی Factory
  • نویسنده : NetBoss
  • پیش نیاز : الگو های طراحی نرم افزار

این الگوی طراحی یک الگوی  Creational میباشد که با استفاده از آن میتوان بطور غیر مستقیم یک آبجکت جدید از یک کلاس را ایجاد نمود. در الگوی طراحی Factory ما بدون افشا ساختن لاجیک ایجاد آبجکت ها برای کاربر آنها را ایجاد نموده و با یک   Interface مشترک به آنها اشاره و از آنها استفاده مینماییم.

مثال فرض کنیم که دو نوع مشتری داریم. مشتری آنلاین و مشتری حقیقی. از این کلاس ها ی مشتری یک Client قرار است استفاده نماید. مثلا ، متدی را صدا بزند که اطلاعات مشتری را نمایش دهد. یک راه برای Client این است که خود، مشتری را ایجاد نموده و عملیات مورد نظر را انجام دهد. این بدین معنی است که، Client باید از نحوه ساخت این کلاس ها اطلاع پیدا نموده و مستقیما در گیر این مسئله شود. حال با استفاده از الگوی طراحی Factory این مشکل را حل کرده و ساخت ابجکت های مورد نظر را به کلاس  واسط  Factory واگذار مینماییم. در اینجا ارتباط بین توسعه دهندگان کلاس بیزینسی مشتری و توسعه دهندگان Client به حداقل رسیده و در نهایت هر یک تنها کلاس Factory را میشناسند و به یکدیگر وابسته نخواهند بود. وابستگی به Factory یعنی وابستگی به Contract (قرارداد)  و یا همان Interface مذکور در مثال فوق. این در حالیست که خوشبختانه Contract  مفهومی نیست که دائما در حال تغییر باشد. یکی از مهمتریم موارد کاربرد الگوی طراحی Factory کاهش وابستگی کلاس های بیزینسی نرم افزار با کلاس های استفاده کننده از بیزینس مثلا UI میباشد. با استفاده از این الگوریتم میتوان توسعه ی پروژه را بطور همزمان پیش برد. این در حالیست که  استفاده از این تکنیک به علت پراکندگی و توزیع کدها، ممکن است بر روی مسئله دیباگ و رهگیری کد های برنامه تاثیر منفی بگذارد.

 تشریح مثال فوق : فرض کنید که در سیستم مکانیزه و اوتوماسیون یک فروشگاه زنجیره ای دو نوع مشتری از نظر مفاهیم بیزنسی وجود داشته باشند. یک مشتری حقیقی که به صورت فیزیکی در فروشگاه حاضر شده و خرید مینماید و دیگری مشتری مجازی که از طریق یک وبسایت اینترنتی محصولات مورد نظر خود را سفارش میدهد. اگر بخواهیم چنین سیستمی را به صورت فرضی پیاده سازی نماییم میبایست این دو کلاس مشتری Interface با نام ICustomer را پیاده سازی نمایند. زیرا هر دو کلاس از نظر رفتاری دارای شباهت های فراوانی هستند که در پیاده سازی متفاوت میباشند. حال فرض کنیم یک نفر وظیفه ساخت UI نرم افزار، و دیگری وظیفه پیاده سازی سرویس ها و بیزینس نرم افزار را بر عهده داشته باشد. اگر قرار باشد برنامه نویس UI مستقیما با کلاس  های بیزنسی ارتباط برقرار نماید، باید بطور دائم خود را با تغییرات آن وقف داده و خود مسئولیت ساخت آبجکت های کلاس را بر عهده بگیرید. در یک نرم افزار کوچک ممکن است چنین مسئله ای ساده و بی اهمیت بنظر برسد. اما در مسائلی که بسیار حجیم و نرخ تغییرات بالا میباشد چنین دیدگاهی به کاهش زمان Develop ختم میشود. این دو برنامه نویس در اولین قدم برای رفع چنین مشکلی با یکدیگر بر روی یک قرار داد که در قالب ICustomer موجود است به توافق میرسند. اینگونه برنامه نویس UI نیازمندی های خود را به برنامه نویس بیزینس اعلام کرده و توافقات را درون Interface مذکور قرار میدهند. در قدم بعدی کلاسی توسط برنامه نویس سوم ایجاد خواهد شد که مسئولیت ایجاد کلاس های بیزینسی (در این مثال مشتریان) را بر عهده میگیرد این کلاس همان کلاس Factory میباشد. نتیجتا وابستگی برنامه نویس UI از برنامه نویس بیزنس قطع شده، سرعت توسعه افزایش و نرخ تغییرات ناشی از اشتاباهات کاهش خواهد یافت.   در تصویر زیر بر اساس قانون Polymorphism کلاس Factory یکی از دو کلاس مشتری حقیقی و یا مجازی را در قالب یک Interface باز میگرداند.  نحوه کار Factory در این مثال به این گونه است که پس از دریافت نام کلاس مورد نظر آبجکتی از آن را New کرده و آن را در قالب ICustomer به برنامه نویس UI باز میگرداند.

الگوی طراحی Factory
الگوی طراحی Factory
One Comment

Add a Comment

Your email address will not be published. Required fields are marked *

Copy Protected by Chetan's WP-Copyprotect.