https://virgool.ir/feed/@m_69038507fa2026-11-12 04:47:26https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_69038507https://virgool.ir/@m_69038507/الگوهای-طراحی-go4-un53vf9wfssnگروه الگوهای طراحی Go4 (Gang Of 4) مجموعه ‌ای از 23 الگوی طراحی است که به مشکلات متداول طراحی نرم‌افزار راهکارهایی ارائه می‌دهند که هر کدام به صورت یک سه گانه ی مشکل-شرایط-راه حل ارائه شده اند. این الگوها بر اساس سه دسته الگویی، شامل الگوهای ایجادی ، ساختاری و رفتاری، دسته ‌بندی می‌شوند. هر الگویی هدف خاص خود را دارد و می‌تواند در صحنه‌های مختلفی استفاده شود.الگو های طراحیدر زیر چند نمونه از الگوهای طراحی Gang of 4، با توضیح آورده شده است:1) الگوهای ایجادی:الگوی Singleton: تضمین می‌کند که فقط یک نمونه از یک کلاس وجود داشته باشد و به آن دسترسی سراسری فراهم می‌کند. این الگو در صورتی کاربردی است که نیاز داریم یک نمونه تک و مشترک از یک کلاس در سراسر سیستم داشته باشیم.مزایا:1. تضمین وجود یک نمونه واحد: الگوی Singleton تضمین می‌کند که یک کلاس تنها یک نمونه از خود را دارد. این به شما امکان می‌دهد که از یک نمونه مشترک در سراسر برنامه استفاده کنید و اطمینان حاصل کنید که همه اجزای برنامه از یک وضعیت یکسان استفاده می‌کنند.2. دسترسی به نمونه از هر جای برنامه: با استفاده از Singleton، شما می‌توانید به نمونه از هر جای برنامه دسترسی پیدا کنید. این مزیت مخصوصاً زمانی مفید است که نیاز به استفاده از یک نمونه مشترک در بخش‌های مختلف برنامه دارید.3. کاهش مصرف منابع: یک نمونه از Singleton تنها یک بار ایجاد می‌شود و پس از آن برای دسترسی به آن از طریق اشاره‌گر استفاده می‌شود. این کاهش مصرف حافظه و منابع سیستم را به دنبال دارد.معایب:1. ایجاد وابستگی‌های مخفی: استفاده از Singletonممکن است به وجود وابستگی‌های مخفی در کدها منجر شود. برنامه‌نویسانی که از Singletonاستفاده می‌کنند، ممکن است برای دسترسی به نمونه از هر جای کد، به صورت مستقیم به آن اشاره کنند و این باعث کاهش شفافیت و قابلیت تست کد می‌شود.2. کاهش قابلیت تست: استفاده از Singleton ممکن است قابلیت تست کد را کاهش دهد. زیرا برای تست قطعات مختلف کد، باید از نمونه Singletonجداگانه‌ای استفاده شود. این موضوع می‌تواند فرآیند تست را پیچیده‌تر کند و باعث افزایش زمان و هزینه توسعه شود.3. مشکلات همزمانی (Concurrency): استفاده از Singleton در برنامه‌های همزمان ممکن است به مشکلات همزمانی منجر شود. زمانی که چند نخ به صورت همزمان به نمونه Singletonدسترسی می‌یابند، ممکن است تداخل‌ها و مشکلات عملکردی به وجود آیند. برای رفع این مشکل، باید روش‌های همزمان‌سازی مناسبی را پیاده‌سازی کنید.باید توجه داشت که استفاده از الگوی Singleton باید با دقت و توجه به نیازهای ویژه برنامه انجام شود. در برخی موارد، استفاده از روش‌های دیگر مانند dependency injection () می‌تواند جایگزین مناسبی برای Singleton باشد.الگوی Factory Method: یک رابط برای ایجاد اشیاء فراهم می‌کند، اما به زیرکلاس‌ها اجازه می‌دهد که تصمیم بگیرند کدام کلاس را نمونه ‌سازی کنند. این الگو در صورتی کاربردی است که می‌خواهیم فرآیند ایجاد اشیاء را به زیرکلاس‌ها واگذار کنیم.مزایا:1. افزایش انعطاف‌پذیری: Factory Method به شما اجازه می‌دهد تا نحوه ایجاد یک شیء را در یک کلاس پایه مشخص کنید، اما متوسط زیرکلاس‌ها را به تعیین نوع و نحوه ساخت شیء بگذارید. این الگو به شما انعطاف‌پذیری بیشتری در تولید شیء و استفاده از نوع‌های مختلف آن‌ها می‌دهد.2.جدا کردن ساخت و استفاده: با استفاده از Factory Method، ساخت شیء از کارکرد آن جدا می‌شود. شما نیازی ندارید تا در سراسر کد خود شیوه ساخت را تکرار کنید و می‌توانید فقط به استفاده از شیء تمرکز کنید.3.قابلیت گسترش: Factory Method به شما امکان می‌دهد که به راحتی نوع جدیدی از شیء را اضافه کنید، بدون اینکه کلاس‌های موجود را تغییر دهید. شما می‌توانید فقط یک زیرکلاس جدید ایجاد کنید که Factory Method را پیاده‌سازی کند و نوع جدیدی از شیء را تولید کند.معایب:1.افزایش پیچیدگی: استفاده از Factory Method ممکن است باعث افزایش پیچیدگی کد شود. هر زمان که نیاز به ایجاد شیء جدیدی داشته باشید، باید یک کلاس زیرکلاس جدید ایجاد کنید و Factory Method را پیاده‌سازی کنید. این ممکن است باعث ایجاد تعداد زیادی کلاس زیرکلاس شود که می‌تواند کد را پیچیده کند.2.ازدیاد تعداد کلاس‌ها: استفاده از Factory Method ممکن است منجر به ایجاد تعداد زیادی کلاس مشابه با تفاوت‌های کوچک شود. این موضوع می‌تواند کد را پیچیده کند و مدیریت آن را سخت‌تر کند.3.نیاز به پیاده‌سازی زیرکلاس: برای استفاده از Factory Method، باید یک کلاس زیرکلاس جدید ایجاد کنید و Factory Method را در آن پیاده‌سازی کنید. این نیاز به پیاده‌سازی مجدد و توسعه‌ی کلاس‌ها ممکن است زمان‌بر و پیچیده باشد.الگوی Abstract factory: یک رابط برای ایجاد خانواده‌ای از اشیاء مرتبط یا وابسته بدون مشخص کردن کلاس‌های مشخص آنها فراهم می‌کند. این الگو در صورتی کاربردی است که می‌خواهیم یک مجموعه ای از اشیاء مرتبط را به همراه کار با هم ایجاد کنیم.مزایا:1.جدا سازی ساختاری از پیاده‌سازی: با استفاده از Abstract Factory، ساختار ایجاد شیء از پیاده‌سازی جدا می‌شود. این الگو اجازه می‌دهد تا یک کد مشترک برای ساخت اجزاء مرتبط در یک خانواده ایجاد کنید، بدون اینکه به جزئیات پیاده‌سازی خاص هر اجزا نیاز داشته باشید. این جداسازی موجب افزایش انعطاف‌پذیری و قابلیت تغییر در برنامه می‌شود.2.پشتیبانی از متعدد برنامه‌ها و سیستم‌ها: با استفاده از Abstract Factory، می‌توانید برای هر برنامه یا سیستم مجموعه‌ای از اجزاء مخصوص تعیین کنید. این به شما امکان می‌دهد تا برنامه را به سادگی توسعه دهید و اجزاء متفاوت را با یکدیگر جایگزین کنید.3.افزایش سطح انتزاع: Abstract Factory اجازه می‌دهد تا برنامه‌نویسان را در سطح بالاتری از انتزاع قرار دهد. آن‌ها با استفاده از یک رابط کلی برای ساخت اجزاء مرتبط، بدون نیاز به دانستن جزئیات پیاده‌سازی، با اجزاء کار کنند. این انتزاع به انعطاف و قابلیت تغییر بیشتر در برنامه کمک می‌کند.معایب:1.پیچیدگی اضافه: استفاده از Abstract Factory ممکن است پیچیدگی را در برنامه افزایش دهد. برای پیاده‌سازی این الگو، باید یک ساختار اضافی را به برنامه اضافه کنید که ممکن است منجر به افزایش تعداد کلاس‌ها و رابط‌ها شود.2.سربار ممکن در عملکرد: استفاده از Abstract Factory ممکن است باعث افزایش سربار در عملکرد برنامه شود. ایجاد یک Abstract Factory و تعامل بین آن و اجزاء مختلف، نیازمند پردازش اضافی باشد که ممکن است تأثیر منفی بر عملکرد کلی برنامه داشته باشد.3.محدودیت در اضافه کردن اجزاء جدید: استفاده از Abstract Factory ممکن است منجر به محدودیت در اضافه کردن اجزاء جدید به برنامه شود. زمانی که نیاز به اضافه کردن اجزاء جدید و خانواده‌های جدید پیش بیاید، باید تغییرات قابل توجهی در Abstract Factory و اجزاء مرتبط صورت گیرد.الگوی Builder: ساخت یک شی را از نمایش آن جدا میکند و در واقع این اجازه را میدهد که همان فرآیند ساخت بتواند نمایش های مختلفی را ایجاد کند.مزایا:1.ساختار مرحله‌بندی شده: الگوی Builder به شما اجازه می‌دهد تا ساختار مرحله‌بندی شده‌ای را برای ساخته شدن یک شیء پیاده‌سازی کنید. این به شما امکان می‌دهد تا فرآیند ساخت یک شیء را در مراحل مختلف تقسیم کرده و نحوه ساخت آن را به صورتی قابل تغییر و قابل تنظیم کنید.2.ایجاد نمونه‌های متنوع: با استفاده از الگوی Builder، شما می‌توانید برای ساخت یک شیء از نوع‌ها و نمایش‌های متنوعی استفاده کنید. هر بار با تنظیم مراحل ساخت در طرح Builder، می‌توانید نوع و نمایش مختلفی از یک شیء را تولید کنید.3.جداشدن ساخت و نمایش: با استفاده از الگوی Builder، شما می‌توانید ساخت و نمایش یک شیء را از هم جدا کنید. این به شما امکان می‌دهد تا فرآیند ساخت را مستقل از نحوه نمایش آن شیء انجام دهید. این امکان را به شما می‌دهد که نمایش شیء را به روش‌های مختلفی تغییر دهید بدون تغییر در فرآیند ساخت.معایب:1.افزایش پیچیدگی کد: استفاده از الگوی Builder ممکن است باعث افزایش پیچیدگی کد شود. تعداد زیادی کلاس و رابطه بین آنها ممکن است برای برنامه‌نویسان سختی‌های قابل توجهی ایجاد کند. همچنین، نیاز به پیاده‌سازی متدهای ساخته‌شدن در کلاس Builder نیز ممکن است کد را پیچیده کند.2.ممکن است منجر به بیش‌برنامه‌ریزی شود: استفاده از الگوی Builder ممکن است باعث بیش‌برنامه‌ریزی شود. زمانی که برای ساخت یک شیء نیاز به مراحل زیادی باشد و نوع‌ها و ویژگی‌های مختلفی را پشتیبانی کند، نیاز به برنامه‌ریزی دقیق‌تر و مدیریت بهتری دارید.3.افزایش زمان و هزینه توسعه: پیاده‌سازی الگوی Builder ممکن است زمان و هزینه توسعه را افزایش دهد. ایجاد کلاس‌ها و رابطه بین آنها، پیاده‌سازی متدهای ساخته‌شدن و تنظیم‌های مورد نیاز، همگی نیازمند زمان و تلاش بیشتری هستند.الگوی Prototype: با کپی کردن شی های موجود، ایجاد شی های جدید را بدون مشخص کردن دقیق کلاس آنها ممکن میکند.مزایا و معایب:1.ایجاد شیء‌های جدید با استفاده از کپی: الگوی Prototype به شما امکان می‌دهد شیء‌های جدید را با استفاده از کپی از شیء‌های موجود ایجاد کنید. این باعث می‌شود برای ایجاد شیء جدید نیازی به ساختار و نحوه ایجاد آن شیء نباشد و کد را ساده‌تر کند.2.افزایش سرعت ایجاد شیء: به جای ایجاد شیء از ابتدا، الگوی Prototype امکان ایجاد کپی شیء‌های موجود را فراهم می‌کند که باعث کاهش زمان و هزینه ایجاد شیء می‌شود.3. پیچیدگی در تعامل با شیء‌های مرتبط: استفاده از Prototype ممکن است باعث پیچیدگی در تعامل با شیء‌های مرتبط شود. هر شیء ممکن است ویژگی‌های خود را بر اساس ویژگی‌های شیءی که از آن کپی گرفته شده است، تغییر دهد و این می‌تواند منجر به پیچیدگی در کنترل و مدیریت شیء‌ها شود.الگوی Object Pool: استفاده مجدد و مدیریت یک استخر از اشیا را برای بهبود عملکرد و کاهش هزینه ایجاد مجدد اشیاء جدید فراهم میکند.مزایا:1.استفاده مجدد از شیء‌ها: الگوی Object Pool به شما امکان می‌دهد شیء‌هایی را که قبلاً ساخته شده‌اند و در دسترس هستند، استفاده مجدد کنید. این باعث افزایش کارایی برنامه و کاهش هزینه ساخت شیء می‌شود.2.کاهش زمان ساخت و حذف شیء: با استفاده از Object Pool، نیازی به ساخت و حذف شیء در هر بار استفاده نیست. شیء‌هایی که قبلاً ساخته شده و در پول قرار دارند، می‌توانند به صورت مجدد استفاده شوند و این باعث کاهش زمان مورد نیاز برای ساخت و حذف شیء می‌شود.معایب:1.پیچیدگی مدیریت شیء‌ها: استفاده از Object Pool ممکن است مدیریت شیء‌ها را پیچیده کند. شما باید مطمئن شوید که شیء‌هایی که در پول قرار می‌گیرند به درستی آزاد شده و برای استفاده‌ی بعدی آماده شوند. همچنین باید توجه داشت که شیء‌ها باید قابلیت چندنخی (Thread-safe) را داشته باشند تا بتوانند به صورت همزمان توسط چند نخ استفاده شوند.2.افزایش مصرف منابع: استفاده از Object Pool ممکن است به افزایش مصرف منابع (مانند حافظه) منجر شود. زیرا شیء‌هایی که در پول قرار دارند، نیاز به حفظ و نگهداری دارند که این منابع را می‌طلبد. بنابراین، باید به دقت و با توجه به نیازهای برنامه از Object Pool استفاده کرد تا به مصرف منابع کنترل شده ایجاد شود.الگوی Lazy Initialization: ایجاد یک شی یا محاسبه ی یک مقدار را تا زمان نیاز واقعی به آن به تاخیر می اندازد.مزایا:1. بهبود عملکرد: با تاخیر در اولیه‌سازی یک شیء یا عملیات، می‌توانید هزینه‌های غیرضروری را از بین ببرید و عملکرد کلی برنامه خود را بهبود ببخشید. منابع فقط در هنگام نیاز واقعی تخصیص داده می‌شوند، که مصرف حافظه را کاهش می‌دهد و اجرا را سریع‌تر می‌کند.2. کاهش زمان راه‌اندازی: اولیه‌سازی تنبل می‌تواند به کاهش زمان راه‌اندازی یک برنامه کمک کند. اگر برخی از اشیاء یا عملیات در زمان اولیه نیاز به استفاده نداشته باشند، می‌توانند بعداً ایجاد یا اجرا شوند و این امکان را به برنامه می‌دهد تا به سرعت شروع شود.3. کارآیی حافظه: اولیه‌سازی تنبل می‌تواند با تخصیص منابع فقط در هنگام نیاز، حافظه را صرفه‌جویی کند. این مزیت به ویژه در مواجهه با اشیاء بزرگ یا پیچیده که مصرف حافظه قابل توجهی دارند، مفید است.4. ایجاد بر اساس درخواست: اولیه‌سازی تنبل به شیء یا عملیات ایجاد بر اساس درخواست اجازه می‌دهد تا همان زمانی که نیاز دارند، در دسترس باشند. این می‌تواند به بهینه‌سازی استفاده از منابع و بهبود کارآیی کلی برنامه شما کمک کند.معایب:1. افزایش پیچیدگی: پیاده‌سازی اولیه‌سازی تنبل می‌تواند پیچیدگی اضافی را به کد شما اضافه کند. این نیازمند مدیریت دقیق ایجاد شیء و همگام‌سازی است تا امنیت نخ‌ها و اولیه‌سازی صحیح تضمین شود.2. تأخیر ممکن: چون اولیه‌سازی تنبل ایجاد یا اجرای اشیاء یا عملیات را به تأخیر می‌اندازد، ممکن است در هنگام دسترسی اولیه به آنها تأخیری رخ دهد. این تأخیر می‌تواند بر پاسخگویی برنامه شما تأثیر بگذارد، به ویژه در حالت‌هایی که دسترسی فوری ضروری است.3. هزینه همگام‌سازی: هنگام استفاده از اولیه‌سازی تنبل در یک محیط چندنخی، ممکن است نیاز به مکانیزم‌های همگام‌سازی برای تضمین ایمنی نخ‌ها وجود داشته باشد. این می‌تواند هزینه و پیچیدگی اضافی را به همراه داشته باشد که ممکن است عملکرد را تحت تأثیر قرار دهد.2) الگوهای ساختاری:الگوی Adapter: رابط یک کلاس را به رابط دیگری که مشتریان نیاز دارند تبدیل می‌کند. این الگو در صورتی کاربردی است که می‌خواهیم کلاس‌های ناسازگار ، با هم دیگر کار کنند.مزایا و معایب:1. این به ما امکان می دهد از کدهای اشخاص ثالث نسبتاً یکپارچه استفاده کنیم. برای استفاده از کد جدید نیازی به تغییر رابط های موجود نیست. فقط یک آداپتور برای آن پیاده سازی کنید.2. گاهی اوقات اصلاح دستی رابط مشتری آسان تر از استفاده از الگوی آداپتور است. اگر از الگوی آداپتور کلاس استفاده می کنید، باید به هر قیمتی از ارث بردن الماس جلوگیری کنید. بعید است که این اتفاق بیفتد، اما اگر این اتفاق بیفتد، با مشکل مواجه خواهید شد.الگوی Bridge: یک موجودیت انتزاعی را از پیاده سازی آن جدا میکند و اجازه میدهد که به صورت مستقل دچار تغییرات شوند.مزایا:1. تعداد کلاس های مورد نیاز برای پیاده سازی سلسله مراتب خاص را تا حد زیادی کاهش می دهد.2. به اصل مسئولیت واحد پایبند است.3. این امکان را برای توسعه هر دو انتزاع و پیاده سازی به طور مستقل فراهم می کند.معایب:1. می تواند کدهای دیگ بخار (کدهایی که به خاطر دلایلی قابلیت اجرا نداشته باشند) زیادی را به وجود آورد.2. همچنین مهاجرت به این ساختار ممکن است دشوار باشد.الگوی Decorator: به یک شیء به صورت پویا وظایف جدیدی را اضافه می‌کند که این کار با قرار دادن آن در یک کلاس دکوراتور (Decorator) صورت میگیرد. این الگو در صورتی کاربردی است که می‌خواهیم رفتارهای اضافی را به اشیاء اضافه کنیم بدون این که کلاس‌های پایه آنها را تغییر دهیم.مزایا و معایب:در نظر گرفتن الگوی طراحی دکوراتور در هنگام طراحی نرم افزار به دلایل مختلفی جواب می دهد. اول از همه، درجه بالایی از انعطاف‌پذیری در هنگام استفاده از ساختار دکوراتور وجود دارد: عملکردهای کلاس‌ها را می‌توان در طول کامپایل و در طول زمان اجرا بدون نیاز به سلسله‌مراتب کلاس‌های مبتنی بر وراثت گیج‌کننده گسترش داد. این به طور قابل توجهی خوانایی کد برنامه را بهبود می بخشد. از آنجایی که عملکرد در چندین کلاس دکوراتور تقسیم می شود، عملکرد نرم افزار را می توان افزایش داد. این امر بازیابی و شروع عملکردهای خاص را آسان می کند. با یک کلاس پایه پیچیده که به طور دائم همه توابع را ارائه می دهد، این گزینه بهینه شده برای منابع در دسترس نیست. با این حال، توسعه با استفاده از الگوی دکوراتور دارای معایبی است. استفاده از الگو پیچیدگی نرم افزار را افزایش می دهد. رابط دکوراتور، به‌ویژه، معمولاً حاوی کدهای زیادی است و اغلب به بسیاری از اصطلاحات مرتبط می‌شود، و آن را به دور از مبتدیان نشان می‌دهد. یکی دیگر از معایب تعداد زیاد اشیاء دکوراتور است که برای جلوگیری از مشکلات نمای کلی مشابه هنگام کار با کلاس های فرعی، سیستم سازی جداگانه ای برای آنها توصیه می شود. زنجیره فراخوانی طولانی اشیاء تزئین شده (یعنی اجزای نرم افزار توسعه یافته) تشخیص خطاها و به طور کلی اشکال زدایی را دشوارتر می کند.الگوی Composite: اشیاء را به ساختارهای درختی تبدیل می‌کند تا سلسله ‌مراتب جز به کل را نمایش دهد. این الگو در صورتی کاربردی است که می‌خواهیم با اشیاء تکی و یا ترکیبی از آنها به طور یکنواخت برخورد کنیم.مزایا و معایب:الگوی ترکیبی در توسعه نرم افزار ثابت است. پروژه‌هایی با ساختارهای تودرتوی شدید تمایل دارند از رویکرد عملی که اشیاء هستند سود ببرند: چه یک شی بدوی باشد یا یک شی مرکب، چه وابستگی‌های ساده یا پیچیده داشته باشد. عمق و عرض تودرتو در الگوی طراحی ترکیبی مهم نیست. تفاوت بین انواع شیء می تواند توسط کلاینت نادیده گرفته شود، بنابراین هیچ توابع جداگانه ای برای یک پرس و جو مورد نیاز نیست. این مزیت را دارد که کد مشتری ساده و ناب است.یکی دیگر از مزایای الگوی ترکیبی، انعطاف پذیری و توسعه پذیری ساده ای است که الگو به یک نرم افزار می دهد. رابط مؤلفه جهانی امکان ادغام اشیاء برگ و ترکیبی جدید را بدون تغییر در کد - چه در سمت مشتری یا ساختارهای شی موجود - فراهم می کند.اما علیرغم تمام مزایای آن، الگوی ترکیبی و رابط یکنواخت آن دارای نقاط ضعفی است. رابط کاربری می تواند برای توسعه دهندگان دردسرساز باشد. پیاده سازی با چندین چالش عمده همراه است. برای مثال، باید از قبل تصمیم گرفته شود که کدام عملیات در اینترفیس و کدام در کلاس های ترکیبی تعریف شوند. تنظیم بعدی خواص ترکیبی (به عنوان مثال، عناصر محدود کننده فرزند) اغلب پیچیده و اجرا کردن آن دشوار است.الگوی Façade: یک رابط ساده شده برای یک زیر سیستم پیچیده فراهم میکند و استفاده از آن را ساده تر میکند و همچنین وابستگی های بین مشتریان و زیر سیستم ها را کاهش میدهد.مزایا و معایب:مزایای الگوی طراحی نما آشکار است: نما، زیرسیستم های نرم افزاری زیرین را پنهان می کند و در نتیجه پیچیدگی این سیستم ها را کاهش می دهد. علاوه بر این، این رویکرد اصل اتصال شل را ترویج می کند. با توجه به درجه کم وابستگی متقابل اجزای جداگانه، تغییرات (اصلاحات، تعمیر و نگهداری) راحت و در هر زمان امکان پذیر است. به دلیل اتصال شل، گسترش یک زیر سیستم آسان تر است.با این حال، استفاده از الگوی طراحی نما دارای معایبی است. به دلیل نقش محوری آن، اجرای نما یک کار خسته کننده و پیچیده است، به خصوص اگر باید در کد موجود درج شود. به طور کلی، نصب یک رابط نما به یک مرحله غیرمستقیم اضافی نیاز دارد، که به نوبه خود زمان محاسبات را برای فراخوانی متد و عملکرد، دسترسی به حافظه و غیره را افزایش می‌دهد.الگوی Proxy: یک نماینده یا جایگزین برای یک شیء دیگر فراهم می کند تا دسترسی به آن را کنترل نماید و یا رفتار های اضافی را اضافه نماید.مزایا:1. دسترسی کنترل شده: الگوی پروکسی به شما امکان می‌دهد تا به دسترسی به شیء واقعی کنترل داشته باشید. می‌توانید منطق اضافی مانند محدودیت‌های دسترسی، تأیید هویت یا کش‌سازی را پیاده‌سازی کنید بدون اینکه کد شیء واقعی را تغییر دهید. این می‌تواند در سناریوهایی که می‌خواهید دسترسی به منابع حساس یا عملیات گرانقیمت را محدود یا مدیریت کنید، مفید باشد.2. افزایش قابلیت‌ها: الگوی پروکسی به شما امکان می‌دهد تا قابلیت‌های اضافی را به شیء واقعی اضافه کنید بدون اینکه کد آن را تغییر دهید. به عنوان مثال، می‌توانید بارگذاری تنبل را پیاده‌سازی کنید، به طوری که شیء واقعی فقط در هنگام نیاز ایجاد یا بارگذاری شود، که عملکرد و استفاده از منابع را بهبود می‌بخشد.3. ساده‌سازی کد مشتری: الگوی پروکسی واسط ساده‌ای را برای مشتری فراهم می‌کند که پیچیدگی دسترسی به شیء واقعی را پنهان می‌کند. مشتری با شیء پروکسی تعامل می‌کند و به عنوان شیء واقعی عمل می‌کند، بدون آگاهی از عملکرد زیرساختی که در پشت صحنه رخ می‌دهد. این می‌تواند کد مشتری را تمیزتر و قابل فهم‌تر کند.4. جداسازی مسئولیت: با استفاده از الگوی پروکسی، می‌توانید مسئولیت‌های کنترل دسترسی، کش‌سازی یا قابلیت‌های اضافی را از شیء واقعی جدا کنید. این ترویج یک کدپایه ماژولار و قابل نگهداری را تسهیل می‌کند با حفظ تمرکز هر کامپوننت بر مسئولیت خاص خود.معایب:1. هزینه میانجی‌گری: الگوی پروکسی لایه‌ای اضافی از میانجی‌گری بین مشتری و شیء واقعی ایجاد می‌کند. این ممکن است در عملکرد و استفاده از حافظه هزینه اضافه‌ای ایجاد کند. با این حال، تأثیر آن به طور کلی قابل توجه نیست مگر اینکه عملیات پروکسی محاسباتی گرانقیمت باشد یا تعداد نمونه‌های پروکسی بسیار زیاد باشد.2. پیچیدگی: الگوی پروکسی ممکن است پیچیدگی اضافی را به کدپایه اضافه کند، به خصوص اگر چندین نوع پروکسی وجود داشته باشد یا اگر منطق پروکسی پیچیده باشد. مهم است که کلاس‌های پروکسی را به طور دقیق طراحی کنید تا از پیچیدگی نازایی جلوگیری کرده و اطمینان حاصل کنید که جداسازی مسئولیت‌ها به خوبی رعایت شده است.3) الگوهای رفتاری:الگوی Observer: وابستگی یک به چند بین اشیاء را تعریف می‌کند، بنابراین هنگامی که یک شیء وضعیت خود را تغییر می‌دهد، تمام وابستگان آن به طور خودکار مطلع و به‌روزرسانی می‌شوند. این الگو در صورتی کاربردی است که می‌خواهید ارتباط بین اشیاء را به صورت یکنواخت برقرار کنید.مزایا:1. اتصال آزاد بین اشیاء را در حالی که آنها با یکدیگر تعامل دارند را فعال می کند.2. به شما امکان می دهد بدون نیاز به تغییر کد موضوع، مشترکین بیشتری اضافه کنید، یعنی از اصل باز/بسته پشتیبانی می کند.3. این به شما امکان می دهد در طول زمان اجرا روابط بین اشیاء ایجاد کنید.4. انعطاف پذیری برای افزودن یا حذف ناظران.معایب:1. اگر الگوی Observer را به طور موثر پیاده سازی نکنید، ممکن است با کد پیچیده و کم کارایی با خروجی نامطلوب مواجه شوید.2. به ترتیب تصادفی ناظران را مطلع می کند.3. ممکن است به دلیل اضافه کردن و حذف صریح ناظران باعث نشت حافظه شود. الگوی Strategy: یک خانواده از الگوریتم‌ها را تعریف می‌کند، هر الگوریتم را توصیف می‌کند و به آنها قابلیت تعویض می دهد. این الگو در صورتی کاربردی است که می‌خواهید الگوریتم را در زمان اجرا انتخاب کنید.مزایا:1. الگوریتم ها را می توان به طور موثر در زمان اجرا تعویض کرد.2. پیاده سازی الگوریتم از کدی که از الگوریتم استفاده می کند جدا شده است.3. ما می‌توانیم استراتژی‌های جدیدی را بدون نیاز به تغییر کد اصلی که الگوریتم را فراخوانی می‌کند، معرفی کنیم.معایب:1. مهندسی بیش از حد زمانی که فقط چند الگوریتم وجود دارد.2. هنگام فراخوانی الگوریتم، مشتریان باید تفاوت های بین استراتژی ها را در نظر بگیرند.الگوی Command: درخواست را به صورت یک شیء بسته‌بندی می‌کند و این امکان را به کاربران می‌دهد که فرستنده درخواست را از گیرنده جدا کنند. این الگو در صورتی کاربردی است که می‌خواهید فرستنده درخواست را از گیرنده آن جدا کنید.مزایا و معایب:1. کاهش وابستگی / جفت شدن سیستم2. دستورات جدید را می توان به راحتی به سیستم اضافه کرد3. اکنون پیاده سازی دستورالعمل های ماکرو آسان تر است.4. استفاده از الگوی طراحی دستور ممکن است به تلاش بیشتری برای پیاده سازی نیاز داشته باشد، زیرا هر دستور به یک کلاس فرمان مشخص نیاز دارد که تعداد کلاس ها را به میزان قابل توجهی افزایش می دهد.الگوی Chain of Responsibility: فرستنده ‌ی یک درخواست را از گیرنده آن جدا می کند به صورتی که برای رسیدگی به یک درخواست چند شیء مختلف وجود دارند. درخواست از زنجیره ای از اشیا رد شده تا به شیء برسد که به درخواست رسیدگی کند. درخواست کننده هیچ اطلاع دقیقی از اینکه درخواست توسط چه شیئی رسیدگی می شود ندارد.مزایا و معایب:1. اين الگو هر شیء را از دانستن اینکه چه کسی به درخواست رسیدگی می کند و اینکه ساختار زنجیر چگونه است آزاد می کند و اینگونه ارتباطات بین اشیا ساده تر می گردد.2. این الگو یک انعطاف پذیری به سیستم می دهد به صورتی که ما با تغییر در زنجیره میتوانیم مسئولیت رسیدگی به درخواست ها را تغییر یا اضافه کنیم.3. از آنجایی که درخواست ها دریافت کننده خاصی ندارند تضمینی وجود ندارد که به درخواست ها رسیدگی شود و اگر زنجیره درست پیکر بندی نشده باشد درخواست ها می توانند با عدم رسیدگی مواجه شوند.الگوی Iterator: روشی برای دسترسی متوالی به عناصر یک شیء تجمعی فراهم میکند بدون اینکه ساختار داخلی شیئ تجمعی را افشا نماید. ایده اصلی این الگو جدا کردن وظایف مربوط به دسترسی و پیمایش های مختلف از شیء تجمعی و افزودن آن به یک شیء iterator می باشد.مزایا و معایب:1. اشیا انبوه می توانند پیچیده بوده و به روش های مختلفی پیمایش شوند که استفاده از iterator این کار را آسان می کند. تنها با جایگزین کردن نمونه آن با دیگری.2. رابط پیمایشی iterator نیاز های مشابه در شیء انبوه را مرتفع می کند در نتیجه رابط آن شیء ساده تر می گردد.3. هر iterator وضعیت پیمایشی خودش را پیگیری می کند پس با استفاده از iterator می توانیم چند پیمایش همزمان بر روی شیء مورد نظر اجرا کنیم.الگوی Mediator: یک شی را تعریف می کند که نحوه تعامل مجموعه ای از اشیا را کپسوله میکند. Mediator با جلوگیری از ارجاع صریح اشیا به یکدیگر، اتصال آنها به یکدیگر را با جلوگیری از ارتباط مستقیم و صریح کم می کند و به شما امکان می دهد تعامل آنها را به طور مستقل تغییر دهید. mediator مسئول کنترل و هماهنگی تعاملات گروهی از اشیا است. Mediator به عنوان واسطه ای عمل می کند که اشیا گروه را از ارجاع صریح به یکدیگر باز می دارد. اشیا فقط mediator را می شناسند و در نتیجه تعداد اتصالات را کاهش پیدا می کنند.مزایا و معایب:1. اتصال بین اشیای که با هم تعامل دارند را کم می کند و این امکان را می دهد که هر کدام از آن ها را به صورت مستقل استفاده کرد یا تغییر داد.2. یک mediator ارتباط چند به چند بین اشیا را به یک ارتباط یک به چند بین mediator و اشیا مرتبط تبدیل می کند. ارتباط یک به چند فهم آسان تری داشته و برای تغییر و گسترش مساعد تر است.3. استفاده از mediator که ارتباط بین اشیا را کپسوله میکند به ما کمک می کند مفهوم که نحوه ارتباط اشیا را از رفتار اشیا جدا کنیم و اینگونه می توانیم بر روی نحوه ارتباط اشیا تمرکز کنیم.4. این الگو پیچیدگی ارتباطات بین اشیا را به پیچیدگی خود mediator تغییر می دهد که این خود می تواند باعث پیچیدگی بالای mediator نسبت به بقیه اشیا شود که نگهداری آن را سخت میکند.الگوی Memento: بدون نقض کپسوله کردن، وضعیت داخلی یک شیء را گرفته و استخراج می کند که اگر آن شیء بعدا خواست که به وضعیت قبل باز گردد اطلاعات لازم برای این کار را داشته باشد. Memento شیء ای است که یک تصویر از وضعیت داخلی یک شی دیگر - the memento's originator - ذخیره می کند. مکانیزم بازگشت زمانی که نیاز به ذخیره وضعیت فعلی originatorداشته باشد، از originator درخواست memento می کند. originator memento را با اطلاعاتی که وضعیت فعلی آن را مشخص می کند مقدار دهی اولیه می کند. فقط originator می تواند اطلاعات را از memento ذخیره و بازیابی کند.مزایا و معایب:1. از افشا کردن اطلاعات خصوصی originator خودداری می کند اما به هر حال این اطلاعات در جایی خارج از originator ذخیره می شوند. این الگو از اطلاعات داخلی originator در مقابل دسترسی دیگر اشیا محافظت می کند پس از کپسوله کردن تخطی نمی کند.2. در دیگر طراحی هایی که کپسوله بودن را پشتیبانی می کنند تمام اطلاعات مربوط به تمام نسخه های originator باید در داخل خود آن ذخیره شود که این تمام وظیفه مدیریت فضا را برعهده originator قرار می دهد که استفاده از memento این مشکل را حل کرده و originator را ساده تر می کند.3. اگر originator اطلاعات زیادی را در memento ذخیره کند یا اینکه کاربر استفاده زیادی از بازگشت به حالت قبل داشته باشد علیرغم اینکه با استفاده از memento هزینه بازگشت به حالت قبل و کپسوله کردن پایین است اما استفاده از این الگو می تواند مناسب نباشد.4. در برخی زبان ها ممکن است دادن اطمینان از اینکه به اطلاعات memento تنها originator می تواند دسترسی داشته باشد سخت است.الگوی State: به یک شیء این قابلیت را می دهد که رفتارش را متناسب با تغییر وضعیتش، تغییر دهد. به صورتی که بنظر میرسد که کلاس مربوط به شیء مورد نظر تغییر کرده است.مزایا و معایب:1. الگوی State تمام رفتارهای مرتبط با یک حالت خاص را در یک شیء قرار می دهد. از آنجایی که کد های هر حالت خاص در یک زیر کلاس State قرار دارند، حالت ها و انتقال های جدید را می توان به راحتی با تعریف زیر کلاس های جدید اضافه کرد.2. هنگامی که یک شیء وضعیت فعلی خود را صرفاً بر اساس مقادیر داده های داخلی مشخص می کند، انتقال حالت آن هیچ نمایش صریحی ندارد. آنها فقط به عنوان تخصیص به برخی از متغیر ها نشان داده می شوند. معرفی اشیا مجزا برای حالت های مختلف، انتقال را واضح تر می کند. همچنین، اشیا State می توانند از Context در برابر حالت ‌های داخلی ناسازگار محافظت کنند، زیرا انتقال ‌های حالت از منظر Context اتمی هستند.الگوی Template Method: ساختار کلی یک الگوریتم را در یک عملیات تعریف کنید، برخی از مراحل را به زیر کلاس ‌ها موکول کنید. الگو Template Method به زیر کلاس‌ ها اجازه می ‌دهد تا مراحل خاصی از یک الگوریتم را بدون تغییر ساختار الگوریتم بازتعریف کنند. Template Method، الگوریتم را بر به صورت abstract تعریف می‌کند که زیرکلاس ‌ها برای ارائه رفتار مشخص، از آن استفاده می کنند.مزایا و معایب:1. ایجاد پیاده‌سازی مشخص از یک الگوریتم نسبتاً آسان است زیرا با استفاده از یک کلاس انتزاعی، بخش‌های مشترک دامنه مشکل را حذف می‌کنید.2. از کد تکراری جلوگیری می کنید.3. کد همیشه پاک‌تر است زیرا الگوریتم را به روش‌ها یا توابع خصوصی جدا می‌کنید که آزمایش آنها ساده‌تر و آسان‌تر است.الگوی Visitor: عملیاتی را که باید بر روی عناصر یک ساختار شیء انجام شود، نشان می دهد. Visitor به شما این امکان را می دهد که یک عملیات جدید را بدون تغییر کلاس های عناصری که بر روی آنها عمل می کند تعریف کنید. هنگامی که یک عنصر visitor را "می پذیرد"، درخواستی را برای visitor ارسال می کند که کلاس عنصر را encode می کند. همچنین عنصر را به عنوان آرگومان شامل می شود. سپس visitor عملیات را برای آن عنصر اجرا می کند - عملیاتی که قبلاً در کلاس عنصر قرار داشت.معایب و مزایا:1. افزودن عملیاتی که به اجزای اشیا پیچیده بستگی دارد را آسان می کنند. شما می توانید یک عملیات جدید را بر روی یک ساختار شی به سادگی با افزودن یک بازدید کننده جدید تعریف کنید. در مقابل، اگر عملکرد را در تعداد زیادی از کلاس‌ ها پخش کنید، باید هر کلاس را تغییر دهید تا عملیات جدیدی تعریف شود.2. رفتار مرتبط در کلاس‌ هایی که ساختار شیئ را تعریف می‌ کنند پخش نمی‌ شوند بلکه در یک visitor محلی شده اند. مجموعه رفتارهای نامرتبط در زیر کلاس های visitor خود تقسیم می شوند.3. یک iterator می تواند اشیاء موجود در یک ساختار را در حین عبور از آنها با فراخوانی عملیات آنها مشاهده کند. اما یک iterator نمی تواند در ساختارهای اشیا با انواع مختلف عناصر کار کند. visitor این محدودیت را ندارد. می تواند از اشیایی که کلاس والد مشترک ندارند بازدید کند. شما می توانید هر نوع شی را به واسط Visitor اضافه کنید.4. هنگام بازدید از هر عنصر در ساختار شیء، می توانند حالت را جمع کنند. بدون visitor، این حالت به عنوان آرگومان های اضافی به عملیات هایی که پیمایش را انجام می دهند منتقل می شود، یا ممکن است به عنوان متغیرهای سراسری ظاهر شوند.5. رویکرد visitor فرض می‌کند که رابط Concrete Element آنقدر قدرتمند است که به visitors اجازه می‌ دهد کار خود را انجام دهند. در نتیجه، این الگو اغلب شما را مجبور می‌کند تا عملیات عمومی را ارائه دهید که به وضعیت داخلی یک عنصر دسترسی دارد، که ممکن است کپسوله شدن آن را به خطر بیندازد.محمد کلهرمحمد کلهرThu, 06 Jul 2023 16:49:34 +0330