نگاه اجمالی به دیزاین پترن

این نوشته ترکیبی از ترجمه کتاب Design Patterns Explained Simply هست به علاوه چیزهایی که خودم از پترن دیزاین میدونستم یا قبلا به صورت تکه تکه توی اینترنت خوندم. در اصل این نوشته تلاش من برای بازنشر اطلاعاتی هست که در این مورد جمع کردم. مطمعنا کامل نیست و اگه نوشته کاملتری داشتید یا برای هرکدوم از الگوها پست خوبی دارید (یا جایی میشناسید) برای من بفرستید لینکش میکنم. خودم هم سعی میکنم هر الگو رو طی یک پست ویرگولی توضیح کاملی بدم بعد از اینکه خودم فهمیدم چی هست.الگوی طراحیتوی مهندسی نرم افزار یه مفهومی هست به اسم دیزاین پترن یا الگوی طراحی. دیزاین پترن ها راه حل های عمومی هستند که میتونن برای مسایل معمول و مختلف توی طراحی نرم افزار استفاده بشن. دیزاین پترن، طراحی نهایی یک محصول نیست و با کد اجرایی فرق داره. دیزاین پترن یک توصیف یا قالبی هست از اینکه یک مساله در شرایط مختلف چجوری باید حل بشه. دیزاین پترن ها باعث میشن نگهداری کد راحت بشه چرا که ساختار کدها یکسان و آشناست. و بعد از گذشت زمان هم درکش راحته. دیزاین پترن ها انواع مختلفی دارند و معمولا به سه دسته اصلی Structural (ساختاری)، Creational (آفرینشی!) و Behavioral (رفتاری) تقسیم میشن. البته دیزاین پترن همیشه مفید نیست و باید بدونید که کجا باید ازش استفاده کرد، نکرد و کدوم رو استفاده کرد. استفاده نادرست ازش میتونه فرآیند کدنویسی رو زجرآور و طولانی کنه.دیزاین پترن ها البته مخالف های مهم و بزرگی هم دارند. یکی از انتقادهایی که به دیزاین پترن هست اینه که بیشتر الگوها برای زبان های قدیمی به طور مشخص برای ++C و small talk بودند و توی زبان های امروزی این کارها توسط خود زبان ساده سازی شدند کلا راه حل دیگه ای ارایه شده. این حرف رو Peter Norvig زده.نظر پل گراهام یک مقداری فلسفی تره. ایشون میگن در بهترین حالت یک مفهوم نباید کپی بشه بلکه باید به اون رفرنس داده بشه از طرف دیگه اگر به چیزی اشاره بشه به جای اینکه کپی بشه دیگه اون چیز نمی تونه الگو باشه.حرف این دو بزرگوار اینه که پترن دیزاین ها مستقل از زبان نیستند و این کمبود برخی زبان ها هست که باعث میشه به این الگو ها نیاز پیدا کنیم. پیتر نورویگ طی یک تحقیقی نشون داده که ۱۶ مورد از ۲۳ پترن دیزاین که توی کتاب Design Patterns هست، که تمرکزش روی ++C بوده دیگه توی زبانهایی مثل Lisp و Dylan توسط امکانات خود زبان ساده سازی شدند و یا توسط پشتیبانی زبان دیگه نیازی بهشون نیست و پیچیدگی اضافه میکنن به کد. از طرفی ایده دیزاین پترن این هست که یک راه حل که در حال حاضر بهترین هست رو استاندارد کنه. خوب این به نظر عالی میاد، ولی در عمل نتیجه تکرارهای غیر ضروری کد هست. معمولا یک راه حل بهینه با پیاده سازی خوب بهتر از یک پترن دیزاین هست. برخی ها هم معتقدند که این مفاهیم با بقیه مفاهیم فرق چندانی نداره و صرفا یک اسم گذاری مجدد روی برخی مفاهیم هست. مثلا MVC که سابقه بیشتری نسبت به پترن دیزاین داره، به عنوان یک دیزاین پترن توی کتاب معرفی شده.الگوهای Creationalاین دیزاین پترن ها تمرکزشون توی ایجاد نمونه از آبجکت ها هستش تا آبجکت رو با توجه به موقعیت به صورت مناسبتر ایجاد کنه. این دیزاین پترن ها سعی می کنن تا پیچیدگی رو کم کرده و بی ثباتی توی ایجاد آبجکت رو کنترل کنند. ایجاد تغییر توی عملگرها معمولا کار دردسرسازی و بعد از گذر زمان تغییر توی توابع و کلاس ها باعث اشکال توی سیستم بشه.الگوی Abstract Factory : ایجاد یک شی که از کلاس های هم خانواده دیگر ارث می برد.الگوی Builder : جداسازی ساختار از نمایش آبجکت.الگوی Factory Method : ایجاد یک آبجکت شامل چند کلاس بطوریکه پردازنده عمل مشخص نشده باشه.الگوی Object Pool : پیشگیری از بدست آوردن و رها کردن منابع پرهزینه توسط بازیافت آبجکت هایی که دیگر استفاده نمی شوند.الگوی Prototype : یک نمونه کاملا مقداردهی شده جهت کپی یا کلون.الگوی Singleton : یک کلاس از آبجکت هایی که فقط یک نمونه از آن باید در سیستم باشد.الگوهای Structuralاین دیزاین پترن ها هدف سهولت طراحی از طریق شناخت یک راه ساده برای برقراری ارتباط بین موجودیت ها را دارد.الگوی Adapter : این پترن مانند یک پل دو اینترفیس ناسازگار را یکجا جمع می کند.الگوی Bridge : اینترفیس آبجکت را از پیاده سازی جدا می کند.الگوی Composite : استفاده از گروهی از آبجکت ها به مانند یک آبجکت.الگوی Decorator : امکان اضافه کردن عملکرد جدید به آبجکت.الگوی Facade : یک کلاس برای دسترسی به کل زیر سیستم.الگوی Flyweight : سعی بر کمینه کردن استفاده از مموری و کاستن از تعداد آبجکت دارد.الگوی Private Class Data : محدود کردن دسترسی به آبجکت.الگوی Proxy : آبجکت برای نمایش و دسترسی به آبجکت دیگر.الگوهای Behavioralاین دیزاین پترن ها با یافتن نحوه ارتباط بین آبجکت ها سعی در الگو کردن نحوه ارتباط دارند. این عامل باعث افزایش انعطاف پذیری در ارتباطات با بیرون از آبجکت می شود.الگوی Chain of Responsibility : یک راه برای ارسال درخواست بین زنجیره ای از درخواست ها بین اشیا.الگوی Command : کپسوله سازی درخواست به عنوان یک آبجکت.الگوی Interpreter : روشی برای اضافه کردن المان های زبان به برنامه.الگوی Iterator : دسترسی متوالی به المان های یک کالکشن.الگوی Mediator : تمرکزش روی تعریف ارتباط ساده بین بین کلاس ها هست.الگوی Memento : استفاده از آبجکت و برگرداندن آن به حالت اولیه بعد از استفاده.الگوی Null Object :‌ بی رفتاری به عنوان رفتار پیش فرض.الگوی Observer : اطلاع دادن تغییرات به کلاس های استفاده کننده.الگوی State : تغییر رفتار آبجکت در هنگام تغییر وضعیت.الگوی Strategy : کپسوله کردن الگوریتم ها در کلاس و استفاده به نسبت شرایط.الگوی Template Method : واگذاری مراحل الگوریتم به زیر کلاس.الگوی Visitor : تعریف عملکرد جدید به کلاس بدون تغییر.