الگوهای طراحی (Design Patterns)

در مهندسی نرم‌افزار، الگوهای طراحی یک راه حل عمومی تکرارشونده برای یک سری از مشکلات رایج در طراحی نرم‌افزار هستش. الگوی طراحی یک طرح به پایان رسیده نیست که بتونه مستقیماً به کد تبدیل بشه و کارش تموم بشه. در واقع توضیح یا الگویی برای نحوه‌ی حل یک مشکل خاص هستش که میتونه توی موقعیت‌های مختلف بارها استفاده بشه.

کاربرد الگوهای طراحی

الگوهای طراحی میتونن با ارائه نمونه‌های توسعه یافته، آزمایش شده و اثبات شده، روند توسعه رو سریع‌تر کنن. طراحی نرم‌افزاری تاثیرگذار، مستلزم در نظر گرفتن مسائلی هستش که ممکنه در بخش پیاده‌سازی قابل مشاهده نباشن. استفاده‌ی چندباره از الگوهای طراحی، از پیش اومدن مسائل ظریفی که میتونن باعث مشکلات عمده بشن جلوگیری میکنه و خوانایی کد رو برای کدنویس‌ها و برنامه نویس‌ها بهتر میکنه.

معمولا افراد فکر میکنن که میتونن از تکنیک‌های طراحی نرم‌افزاری خاص، برای مشکلات خاص استفاده کنن. ولی کاربرد همچین تکنیک‌هایی برای طیف وسیع‌تری از مشکلات سخت هستن. توی چنین مواقعی الگوهای طراحی راه‌حل‌های کلی ارائه میدن. اونها توی قالبی قرار گرفتن که به جزئیات مرتبط با هر مشکل خاص، نیاز ندارن.

علاوه بر این، این الگوها به توسعه‌دهنده‌ها اجازه میدن تا با استفاده از نام‌های شناخته شده و قابل اعتماد برای تعاملات نرم‌افزاری ارتباط بیشتری برقرار کنن. الگوهای طراحی متداول رو میشه در طول زمان بهبود داد، و همین موضوع اونها رو قوی‌تر از طرح‌های ad-hoc میکنه. الگوهای طراحی به سه گروه اصلی تقسیم‌بندی میشن:

الگوهای طراحی خلاقانه

این الگوهای طراحی بیشتر در مورد نمونه‌سازی کلاس‌ها هستن. این الگوها رو میتونید بیشتر به الگوهای ایجاد کلاس و الگوهای ایجاد اشیا تقسیم کرد. در حالی که الگوهای ایجاد کلاس از وراثت به طور مؤثر توی فرآیند نمونه‌سازی استفاده می‌کنن، الگوهای ایجاد شی به طور مؤثر از نمایندگی اختیار برای انجام کار استفاده می‌کنن.

• الگوی Abstract Factory

نمونه‌ای از چندین خانواده از کلاس‌ها رو ایجاد میکنن.

• الگوی Builder

ساخت شی رو از نمایش اون جدا میکنن.

• الگوی Factory

نمونه‌ای از چندین کلاس مشتق شده ایجاد میکنن.

• الگوی Object Pool

با بازیابی اشیایی که دیگر مورد استفاده قرار نمیگرن، از آزادسازی منابع و دسترسی پرهزینه جلوگیری میکنه.

• الگوی Prototype

یک نمونه کاملاً اولیه که باید کپی یا کلون بشه.

• الگوی Singleton

کلاسی که فقط یک نمونه از اون میتونه وجود داشته باشه.

الگوهای طراحی ساختاری

این الگوهای طراحی ترکیبی از کلاس و شی رو دربر میگیرن. الگوهای طراحی ساختاری، از وراثت برای ایجاد رابط‌ها استفاده میکنن. الگوهای ساختاری اشیا راه‌‌هایی رو برای ترکیب اونها و به دست آوردن عملکرد جدید تعریف میکنن.

• الگوی Adapter

رابط‌های کلاس‌های مختلف رو مطابقت میده.

• الگوی Bridge

رابط یک شی رو از پیاده‌ساز اون جدا میکنه.

• الگوی Composit

ساختار درختی از اشیاء ساده و مرکب هستش.

• الگوی Decorator

مسئولیت‌ها رو به صورت پویا به اشیا اضافه میکنه.

• الگوی Facade

یک کلاس واحد که یک زیر سیستم کامل رو نشون میده.

• الگوی Flyweight

یک نمونه با جزییات کوچیک برای اشتراک‌گذاری کارآمده.

• الگوی Private Class Data

دسترسی Accessor/mutator رو محدود میکنه.

• الگوی Proxy

شیئی که نمایانگر یه شی دیگه هستش.

الگوهای طراحی رفتاری

این الگوهای طراحی، ارتباطات اشیاء کلاس رو بررسی میکنه. الگوهای رفتاری اون دسته از الگوهایی هستن که به طور خاص به ارتباط بین اشیا مربوط میشن.

• الگوی Chain of responsibility

راهی برای ارسال درخواست بین زنجیره‌ای از اشیاء هستش.

• الگوی Command

کپسوله کردن درخواست فرمان به عنوان یک شی.

• الگوی Interpreter

راهی برای گنجوندن عناصر زبان در یک برنامه.

• الگوی Iterator

دسترسی به صورت متوالی به عناصر یک مجموعه.

• الگوی Mediator

تعریف ارتباط ساده بین کلاس‌ها

• الگوی Memento

گرفتن و بازیابی حالت داخلی یک شی

• الگوی Null Object

طراحی شده تا به عنوان مقدار پیش‌فرض یک شی عمل کنه.

• الگوی Observer

راهی برای اطلاع‌رسانی تغییر به تعدادی از کلاس‌ها

• الگوی State

وقتی یک شیء تغییر میکنه، رفتار اون تغییر کنه

• الگوی Strategy

کپسوله کردن الگوریتم درون یک کلاس کپسوله

• الگوی Template

موکول کردن مراحل دقیق یک الگوریتم به یک زیر کلاس

• الگوی Visitor

تعریف یک عملیات جدید برای یک کلاس بدون تغییر

ایرادات الگوهای طراحی

مفهوم الگوهای طراحی توسط برخی توی حوزه علوم کامپیوتر مورد انتقاد قرار گرفته از جمله اینکه:

• مشکل اشتباه را هدف قرار میدهد

نیاز به الگوها ناشی از استفاده از زبان‌های کامپیوتری یا تکنیک‌هایی با توانایی ناکافی جداسازی، هستش. به خاطر فاکتورسازی ایده‌آل، یک مفهوم نباید کپی بشه، بلکه صرفاً باید ارجاع داده بشن. اما اگر به جای کپی به چیزی ارجاع داده بشه، «الگویی» برای برچسب زدن و فهرست‌بندی وجود نداره. پل گراهام در مقاله Revenge of the Nerds در این باره حرف میزنه.

پیتر نورویگ هم استدلال مشابهی رو ارائه میده. اون نشون میده که 16 الگو از 23 الگوی کتاب الگوهای طراحی (که عمدتاً روی C++ متمرکزه) در Lisp یا Dylan ساده یا حذف شدن (از طریق پشتیبانی مستقیم زبان).

• فاقد بنیادهای رسمی

مطالعه الگوهای طراحی بیش از حد موردی شدن و بعضی‌‌‌ها به همین دلیل استدلال کردن که این مفهوم به شدت نیاز به قرار گرفتن توی بستر رسمی‌تری داره. در OOPSLA 1999، گروه Gang of Four (با همکاری کامل اونها) در معرض یک محاکمه نمایشی قرار گرفتن، که توی اون به جنایات متعدد علیه علوم رایانه متهم شدن. اونها توسط ⅔ از هیئت منصفه که در دادگاه شرکت کرده بودن محکوم شدن.

• منجر به راه حل‌های ناکارآمد میشه

ایده‌ی الگوی طراحی، تلاشی برای استانداردسازی بهترین شیوه‌های پذیرفته شده قبلی هستن. در اصل استفاده از اونها ممکنه که مفید به نظر برسه، اما در عمل بیشتر اوقات منجر به تکرار غیر ضروری کد میشه. تقریباً همیشه راه حل کارآمدتری برای استفاده از کدها با فاکتور مناسب به جای یک الگوی طراحی (فقط به اندازه کافی خوب) وجود داره.

• تفاوت قابل توجهی با سایر جداسازی‌ها نداره

بعضی از نویسنده‌ها ادعا می کنن که الگوهای طراحی، تفاوت قابل توجهی با سایر شکل‌های جداسازی ندارن و استفاده از اصطلاحات جدید (که از جامعه معماری گرفته شده) برای توصیف پدیده‌های موجود در زمینه برنامه‌نویسی، غیر ضروری هستش. پارادایم Model-View-Controller به عنوان نمونه‌ای از یک الگو معرفی میشه که چندین سال قبل از مفهوم الگوهای طراحی به رسمیت شناخته شده بود. به‌علاوه بعضی استدلال می‌کنن که مشارکت اولیه جامعه الگوهای طراحی (و کتاب Gang of Four) استفاده از زبان الگوی الکساندر به عنوان شکلی از مستندات بوده. عملی که اکثرا توی پیشینه موضوع نادیده گرفته میشه.