الگوهای طراحی
Design Patternها یکسری جواب های ثابت شده به مشکلات رایج در طراحی هستند. به وسیله آنها می توان یکسری راهکار برای حل مسائل بازگشتی در طراحی برنامه تعریف کرد. به طور واضح، Design Patternها کدهای آماده ای نیستند که بتوان مستقیماً از آن ها استفاده کرد. اما یسکری رویکرد یا نظریه برای حل چالش های عادی طراحی ارائه می دهند.
الگوهای Gang Of Four
الگویی است جهت تزریق dependency خارجی یک کلاس به آن، به جای استفاده مستقیم از dependency ها در درون کلاس.
Design Patternها در زمان طراحی سیستم های نرم افزاری و یا فرایند تولید جواب بسیار مورد توجه قرار می گیرد. الگوها سر و صدای زیادی به پا کرده است. از طرفی ممکن است در استفاده از آن ها دچار سردرگمی بشویم.
خیلی وقت ها نیاز است که فقط یک نمونه از یک کلاس ساخته شود. مثلاً وقتی که نمی خواهیم وضعیت شی تغییر کند و یا می خواهیم class را به صورت stateless نگه داریم.
در استفاده از Factory Pattern دو هدف دنبال می شود. یکی loose coupling بین client و لایه business و دیگری نگهداری تمام کدهای مربوط به منطق ساخت شی در یک جای مشخص.
درواقع Abstract factory pattern مرحله بعد از Simple Factory pattern است که در آن Factoryهای مرتبط به هم و یا کلاس های هم خانواده را مشخص می کنیم.
Factory Method Pattern اما با کمی تفاوت، مشابه Simple factory pattern است. بر خلاف Simple factory، client ها دیگر کلاس factory را فراخوانی نمی کنند و به جای آن اینترفیس factory را صدا می زنند. اینترفیس factory بعداً، زمانی که ساخت شی انجام شد، پیاده سازی می شود.
Prototype الگوی طراحی ای است که اشیاء را مجبور می کند تا در زمان ساخت، کپی یا شبیه سازی شوند.
از این الگو برای ساخت اشیاء به صورت جزء به جزء یا به عبارت دیگر مرحله به مرحله استفاده می شود. منطق پیچیده ساخت شی از client جدا شده است و client با ارسال مجموعه ای از جزئیات، شی و اطلاعات مورد نیاز را بدست می آورد.
زمانی که شما چندین SubSystem یا کلاس دارید، برای client سخت خواهد بود که با تمام آنها تعامل داشته باشد و اگر به هر ترتیبی client موفق به مدیریت این تعاملات بشود، کدهای ما خیلی پیچیده و درهم می شود و امکان نگهداری را برای تغییرات آتی سخت خواهد کرد.
الگوی Adapter دو اینترفیس ناهمسازگار، که کارایی های یکسانی دارند اما نحوه فراخوانی متدهایشان متفاوت است، را به هم متصل میکند. گاهی اوقات به عنوان Warapper یا پوشاننده نیز شناخته می شود.
اگر بخواهیم به صورت پویا یک مسئولیت یا قابلیت را به هر شی ای واگذار کنیم، به جای Subclass کردن، می توان از الگوی Decorator استفاده کرد.
در صورتی که بیش از یک متد abstract داشته باشیم و روش های مختلفی برای پیاده سازی آنها وجود داشته باشد، آنگاه باید برای هر نسخه abstract یک کلاس جدید ایجاد کرد و در آخر ممکن است با کلاس های زیادی مواجه شویم. الگوی Bridge برای حل این مشکل یک راه حل ارائه کرده است. در این الگو یک اینترفیس به عنوان یک پل (Bridge) بین کلاس های Abstract و معمولی، معرفی می شود.
شرایطی را در نظر بگیرید که یکسری داده به صورت سلسله مراتبی در اختیار داریم که در آن اشیاء منفرد به صورت برگ و اشیاء ترکیبی به صورت غیر برگ هستند و در هر دو حالت به یک شکل با آنها رفتار می شود. در این صورت باید از الگوی Composite استفاده کرد.