دیزاین پترن ها یا الگو هایی از بزرگان!

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

این اتفاق سمت برنامه نویسی هم میوفته. فرض کنیم من یه منبع دارم که دیتا توش نوشته و ازش خونده میشه (دیتابیس دیگه) من نمیخوام همه ی اکتورها هر وقت و هر طور که دوست دارن به این منبع دسترسی داشته باشن. . من میخوام فقط یه راه ارتباطی برای این منبع وجود داشته باشه و فقط یه راه.هر کس از هرجای برنامه میخواد دیتایی بخونه یا بنویسه باید از این مسیر اقدام کنه و نمیتونه برای خودش کانکشن جدایی بسازه.در این صورت فرایندگرفتن کانکشن به دیتابیس به این صورت خواهد بود که وقتی درخواست دریافت کانکشن رو کسی صدا میزنه، چنانچه از قبل کانکشن بازی با دیتابیس وجود داشته باشه، اون کانکشن باز به درخواست دهنده برگردونده میشه و کانکشن جدید فقط در صورتی ساخته میشه که کانکشن بازی وجود نداشته باشه. این مثالیه که ممکنه برای موارد دیگه ای هم اتفاق بیوفته. یعنی الگویی به این صورت که ما بخوایم از یه موجودیت توی سیستم، فقط یه نمونه داشته باشیم. اینجاست که راه حل مثل قضیه موتور، یه راهکار مشترکه که اونو به عنوان دیزاین پترن سینگلتون میشناسیم.
بقیه دیزاین پترن ها هم طی همچین فرایندی به وجود اومدن، یعنی پاسخ دهنده ی یه نیاز مشترک در مساله های مشترک هستن که طی پروژه های مختلف تکرار شدن.
این دیزاین پترن ها عموما به سه دسته تقسیم میشن که هر کدوم رو با مثال توضیح میدم:
اول creational
الگوهایی هستن که فرایند ساخت یک نمونه از یک چیز رو انتزاعی میکنن. یعنی چی، یعنی اینکه به سیستمی که داره ازشون استفاده میکنه کمک میکنن، مستقل از اینکه یه آبجکت (نمونه) چطور ساخته و پرداخته و سر هم میشه، بتونه . یه نمونه از اونو دریافت بکنه. که مثالش میشه همین سینگلتونی که قبلا معرفی شد.
اواع دیگه ای هم داره مثل فکتوری، ابسترکت فکتوری، بیلدر و پروتو تایپ پترن که هر کدوم توضیح و کاربرد خودشون رو دارن که هرکدومو سرچ کنین، قطعا توضیحات خوبی راجع بهش میتونین پیدا کنین.

دوم structural
الگو هایی هستن که با ترکیب اجزای کوچکتر(میتونن کلاس آبجکت یا اینترفیس باشن) اجزای بزرگتری رو میسازن و برای این کار از مفاهیم ارث بری بهره میگیرن. البته توی مواردی، شامل الگوهایی هم میشن که یه اینترفیس رو به یه اینترفیس دیگه تبدیل و ترجمه میکنن.(آداپتر ها از این دسته هستن)
بریج، کامپوزیت کردن و دکوریتور ها از انواع این الگو ها هستن.

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

در اصل تسلط بر دیزاین پترن ها میطلبه که دولوپری که ما و شما باشیم در عمل و در کیسهایی که بهشون نیاز داریم ازشون استفاده کنیم و این امکان پذیر نیست الا اینکه نوعهای مختلفشو ن رو مطالعه کنیم و برای کیس های مشابهشون آماده باشیم.

#design_patterns