SE_LAB_06

Software Enginering Lab 06 - Mohammad Hossein Gheisarieh - Mohammad Heidary

97110071-97106238

شرح پیاده‌سازی الگوها

Abstract Factory

ابتدا تست مربوطه را می‌نویسیم. سازنده پیتزای پپرونی و پیتزای ماشروم را ایجاد کرده و از روی آن ها پیتزا و رویه پپرونی و ماشروم را ایجاد می‌کنیم. سپس نام و رویه پیتزاها را بررسی می‌کنیم که با مقدار مورد نظر ما برابر باشند. در ابتدا با خطای نبود کلاس ها رو به رو خواهیم شد.

برای ایجاد کلاس‌ها ابتدا interface های pizza , pizzaFactory , Topping را ایجاد کرده و سپس سازنده پیتزاها و رویه‌ها و خود پیتزا ها را از آن ها ارث میبریم. برای رویه و پیتزا صرفا یک رشته در نظر می‌گیریم. برای سازنده پیتزاها پیتزا و رویه لحاظ می‌کنیم. ابتدا برخی از رشته ها را غلط وارد می‌کنیم. با خطا رو به رو می شویم. رشته ها را اصلاح می‌کنیم. تا تست ها پاس شوند.

Prototype

ابتدا تست مربوطه را می‌نویسیم. پروتوتایپ مربوطه را می‌سازیم. از روی آن یک کلاس از نوع کلاینت می‌سازیم. سپس یک پروتایپ کپی از روی آن می‌سازیم. بررسی می‌کنیم که آیا این کپی از جنس کلاینت است خیر؟ در ابتدا با خطای نبود کلاس ها رو به رو می‌شویم.

سپس interface پروتوتایپ را می‌سازیم. کلاس ConcretePrototype که از این interface ارث برده است را می‌سازیم. سپس Client را تکمیل کرده که در آن پروتوتایپ و ایجاد کپی پیاده سازی شده است.

Builder

ابتدا تست مربوطه را می‌سازیم. در تست ابتدا PizzaDirector و PizzaBuilder را می‌سازیم. سپس پیتزا را از روی این دو می‌سازیم. باید مقدار استرینگ پیتزا مناسب باشد. در ابتدا خطا خواهیم خورد.

در ادامه پیتزا را با خصوصیات dough و sauce و topping می‌سازیم. و تابع toString آن را به صورت اشتباه پیاده سازی می‌کنیم. PizzaDirector یک تابع buildPizza دارد که PizzaBuilder دریافت می‌کند. interface مربوطه PizzaBuilder را ایجاد میکنیم. PeperoniPizzaBuilder را از آن ارث بری کرده و توابع مربوطه را implement میکنیم. در اجرای تست حال خطا خواهیم خورد. تابع را اصلاح میکنیم و تست پاس خواهد شد.

پاسخ به سوالات

۱

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

۱. الگوهای ساختاری (Structural Patterns): این الگوها را برای ساختاردهی اجزای یک سیستم نرم‌افزاری به کار می‌بریم. برخی از این الگوها شامل Adapter، Bridge، Composite، Decorator، Facade و Proxy هستند.

۲. الگوهای رفتاری (Behavioral Patterns): این الگوها برای مدیریت رفتارهای اجزای یک سیستم نرم‌افزاری به کار می‌بریم. برخی از این الگوها شامل Chain of Responsibility، Command، Interpreter، Iterator، Mediator، Memento، Observer، State، Strategy و Template Method هستند.

۳. الگوهای ایجادی (Creational Patterns): این الگوها برای ایجاد اجزای یک سیستم نرم‌افزاری به کار می‌بریم. برخی از این الگوها شامل Abstract Factory، Builder، Factory Method، Prototype و Singleton هستند.

۲

سه الگوی طراحی Abstract Factory و Builder و Prototype جزو دسته الگوهای ایجادی (Creational Patterns) می‌باشند.

۳

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

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

۴

الگوی طراحی Singleton اصل Dependency Inversion را نقض نمی‌کند، اما ممکن است با اصل Single Responsibility در تضاد باشد.

اصل Single Responsibility می‌گوید که هر کلاس یا اشیاء باید مسئولیت یک کار را بر عهده داشته باشد و از این رو، باید تغییرات در یک کلاس به دلیل تغییر در یک وظیفه به حداقل رسیده و تغییرات به کل کد سرایت نکند. اما الگوی طراحی Singleton، یک کلاس را مسئول برقراری یک نمونه از خود در سراسر برنامه می‌کند که ممکن است باعث شود که این کلاس برای بسیاری از وظایف مورد استفاده قرار گیرد. در نتیجه، این می‌تواند باعث شود که کلاس Singleton وظایف بیش از حدی بر عهده داشته باشد. این مسئله در تضاد با اصل Single Responsibility است. می‌توان گفت که الگوی طراحی Singleton الزاما نقض اصل Single Responsibility نیست، اما ممکن است با آن در تضاد باشد.