بعضی وقتا برامون پیش میاد که میخوایم توی کدمون یه کاری انجام بدیم، اما خبر نداریم از قبل براش الگو هایی طراحی شده که دونستن اونا خیلی کارمون رو جلو میندازه. پس خیلی خوب میشه اگه با تعریف و کاربردهای design pattern هایی که بیشتر استفاده میشه یه آشنایی کلی داشته باشیم. توی این پست میخوایم یه تعریف کلی از کاربردای تعدادی از design pattern ها داشته باشیم.
قبل از همه بگم که سایت ریفکتورینگ در زمینه design pattern یا الگوهای طراحی خیلی خوب عمل کرده، من هم برای نگارش این پست ازین سایت استفاده کردم. این سایت design pattern ها رو توی سه تا دسته بدی قرار داده:
این دسته از design patter ها روش های مختلف ساختن شئ رو بهمون میگن. چند تا الگو هایی که توی این دسته قرار میگیرن:
مثلا شما یه کسب و کار مدیریت حمل و نقل دارید. کسب و کارتون هنوز کوچیکه و فعلا فقط پیک موتوری دارید. دیزاین پترن کارخونه پیشنهاد میکنه به جای اینکه فقط یه کلاس موتور بسازید. بیاید یه اینترفیس بسازید و اسمش رو بزارید حمل و نقل همه متد هایی که یه وسیله ی حمل و نقل باید اونو داشته باشن رو توی این بسازید و حالا کلاس پیک موتوری‌تون رو ازون implement کنید. این خیلی بهتره. چون بعدا خیلی راحت و بدون اینکه نگران باشید ساختار کدتون به هم بخوره میتونید بهش سواری، وانت، یا وسایل دیگه‌ای اضافه کنید. همونطور که میدونید این اصل open/close سالید رو هم فراهم میکنه.
کارخونه، یه interface برای ساختن اشیاء فراهم میکنه. یه جوری که به زیرکلاس ها اجازه میده نوع اشيایی که ایجاد میشه رو تغییر بدن.
این الگوی طراحی مثل الگوی طراحی قبلی هست با این تفاوت که اینجا چند تا interface داریم و آبجکت های ما میتونن یک یا چند تای اونو پیاده سازی کنن. برای این هم یه مثال بزنیم:
شما فرض کن یه سیستم فروش سرویس چوب منزل داری. یعنی هم مبلمان هم میز ناهار خوری هم انواع صندلی یا حتی مبل های تک نفره. خب مثلا ما یه interface پدر داریم به اسم «سرویس چوب». این interface خودش سه تا کلاس فرزند داره: «مبل»، «صندلی»، «میز». خیلی عالی. حالا ما مبل های تک نفرمون رو کجا بزاریم؟
کارخونه انتزاعی میگه تو الان ۳ تا دسته بندی داری «مبل»، «صندلی» و «میز». هر کدوم ازینا رو یک interface کن. حالا هر کدوم از محصولاتت میتونن کلاس های فرزند باشن که یک یا چند تا از سه تا interface «مبل»، «صندلی» و «میز» رو پیاده سازی میکنن. حالا مبل های تک نفرمون میتونن هم «مبل» رو implement کنن و هم «صندلی» رو.
فرض کنید شما یه سیستمی طراحی خونه دارید. خونه ها اجزا خیلی زیادی رو میتونن داشته باشن یا نداشته باشن. مثلا در، پنجره، سقف، سیستم گرمایشی، حیاط جلویی، حیاط پشتی، سیم کشی برق، شیر آلات، ایوون و ... اینجا الگوی طراحی سازنده پیشنهاد میکنه که شما برای هر کدوم از اجزا خونه متد سازنده داشته باشید و سازنده خونه بیاد این متد ها رو مرحله به مرحله رو فراخوانی کنه. مطمئنا بعضی از این متدها پیاده سازیشون الزمانی هست و بعضی ها اختیاری.
این الگوی طراحی بهمون کمک میکنه که با یه کلاس یکسان شکل ها و نوع های مختلفی از آبجکت ها رو مرحله به مرحله بسازیم.
این الگوی طراحی به ما کمک میکنه که از یه آبجکت موجود کپی برداری کنیم، بدون اینکه بخوایم متدها یا پراپرتی های کلاسش رو صدا بزنیم. مثلا چی؟
مثلا شما یه آبجکت از کلاس ربات رو با یه فرایند خیلی طولانی و پیچیده ساختید. حالا نیاز دارید یه ربات دیگه داشته باشید دقیقا شبیه ربات قبلی علاوه بر سیبیل. مطمئنا حوصله نداریم بریم از اول یه ربات دیگه بسازیم. اینجا این الگوی طراحی میاد کمکمون. یه کپی از ربات اولیتون برمیدارید. حالا یه آبجکت مستقل داریم. میتونید بهش سیبیل اضافه کنید یا هر تغییر دیگه ای روش انجام بدید.
این الگوی طراحی بهمون کمک میکنه که کلاسمون رو جوری بسازیم که ازش فقط و فقط یه آبجکت داشته باشیم و از سراسر برنامه هم بتونیم به اون یدونه آبجکت دسترسی داشته باشیم.
مثلا برای اتصال به دیتابیس ما فقط یه بار باید به دیتابیس کانکشن بزنیم و ازون به بعد هر بار کاری با دیتا بیس داشتیم از همون آبجکت قبلی استفاده کنیم. اینجا دیزایت پترن singleton برامون این رو فراهم میکنه
