این نوشته ترکیبی از ترجمه کتاب Design Patterns Explained Simply هست به علاوه چیزهایی که خودم از پترن دیزاین میدونستم یا قبلا به صورت تکه تکه توی اینترنت خوندم. در اصل این نوشته تلاش من برای بازنشر اطلاعاتی هست که در این مورد جمع کردم. مطمعنا کامل نیست و اگه نوشته کاملتری داشتید یا برای هرکدوم از الگوها پست خوبی دارید (یا جایی میشناسید) برای من بفرستید لینکش میکنم. خودم هم سعی میکنم هر الگو رو طی یک پست ویرگولی توضیح کاملی بدم بعد از اینکه خودم فهمیدم چی هست.
توی مهندسی نرم افزار یه مفهومی هست به اسم دیزاین پترن یا الگوی طراحی. دیزاین پترن ها راه حل های عمومی هستند که میتونن برای مسایل معمول و مختلف توی طراحی نرم افزار استفاده بشن. دیزاین پترن، طراحی نهایی یک محصول نیست و با کد اجرایی فرق داره. دیزاین پترن یک توصیف یا قالبی هست از اینکه یک مساله در شرایط مختلف چجوری باید حل بشه. دیزاین پترن ها باعث میشن نگهداری کد راحت بشه چرا که ساختار کدها یکسان و آشناست. و بعد از گذشت زمان هم درکش راحته. دیزاین پترن ها انواع مختلفی دارند و معمولا به سه دسته اصلی Structural (ساختاری)، Creational (آفرینشی!) و Behavioral (رفتاری) تقسیم میشن. البته دیزاین پترن همیشه مفید نیست و باید بدونید که کجا باید ازش استفاده کرد، نکرد و کدوم رو استفاده کرد. استفاده نادرست ازش میتونه فرآیند کدنویسی رو زجرآور و طولانی کنه.
دیزاین پترن ها البته مخالف های مهم و بزرگی هم دارند. یکی از انتقادهایی که به دیزاین پترن هست اینه که بیشتر الگوها برای زبان های قدیمی به طور مشخص برای ++C و small talk بودند و توی زبان های امروزی این کارها توسط خود زبان ساده سازی شدند کلا راه حل دیگه ای ارایه شده. این حرف رو Peter Norvig زده.
نظر پل گراهام یک مقداری فلسفی تره. ایشون میگن در بهترین حالت یک مفهوم نباید کپی بشه بلکه باید به اون رفرنس داده بشه از طرف دیگه اگر به چیزی اشاره بشه به جای اینکه کپی بشه دیگه اون چیز نمی تونه الگو باشه.
حرف این دو بزرگوار اینه که پترن دیزاین ها مستقل از زبان نیستند و این کمبود برخی زبان ها هست که باعث میشه به این الگو ها نیاز پیدا کنیم. پیتر نورویگ طی یک تحقیقی نشون داده که ۱۶ مورد از ۲۳ پترن دیزاین که توی کتاب Design Patterns هست، که تمرکزش روی ++C بوده دیگه توی زبانهایی مثل Lisp و Dylan توسط امکانات خود زبان ساده سازی شدند و یا توسط پشتیبانی زبان دیگه نیازی بهشون نیست و پیچیدگی اضافه میکنن به کد. از طرفی ایده دیزاین پترن این هست که یک راه حل که در حال حاضر بهترین هست رو استاندارد کنه. خوب این به نظر عالی میاد، ولی در عمل نتیجه تکرارهای غیر ضروری کد هست. معمولا یک راه حل بهینه با پیاده سازی خوب بهتر از یک پترن دیزاین هست. برخی ها هم معتقدند که این مفاهیم با بقیه مفاهیم فرق چندانی نداره و صرفا یک اسم گذاری مجدد روی برخی مفاهیم هست. مثلا MVC که سابقه بیشتری نسبت به پترن دیزاین داره، به عنوان یک دیزاین پترن توی کتاب معرفی شده.
این دیزاین پترن ها تمرکزشون توی ایجاد نمونه از آبجکت ها هستش تا آبجکت رو با توجه به موقعیت به صورت مناسبتر ایجاد کنه. این دیزاین پترن ها سعی می کنن تا پیچیدگی رو کم کرده و بی ثباتی توی ایجاد آبجکت رو کنترل کنند. ایجاد تغییر توی عملگرها معمولا کار دردسرسازی و بعد از گذر زمان تغییر توی توابع و کلاس ها باعث اشکال توی سیستم بشه.
این دیزاین پترن ها هدف سهولت طراحی از طریق شناخت یک راه ساده برای برقراری ارتباط بین موجودیت ها را دارد.
این دیزاین پترن ها با یافتن نحوه ارتباط بین آبجکت ها سعی در الگو کردن نحوه ارتباط دارند. این عامل باعث افزایش انعطاف پذیری در ارتباطات با بیرون از آبجکت می شود.
