9/21/2018 Sima Emadi

فصل اول مقدمه الگوهای طراحی در واقع تجربیات برنامه نویسان خبره است که به صورت الگویی قابل استفاده در همه نرم افزارها در آمده است. برنامه نویسان می توانند با استفاده از این الگوها از تجربیات گرانبهای دیگران در نظم دهی و سازمان دهی کدهایشان استفاده کنند. در مهندسی نرم افزار یک الگوی طراحی، یک روش حل قابل تکرار برای مسائلی هست که عموماً در طراحی نرم افزار با آن برخورد می کنیم. یک الگوی طراحی یک قالب یا شرح برای چگونگی حل مسائلی است که می تواند در شرایط مختلف استفاده شود. یک الگوی طراحی، راه حلی است که برای مستند سازی ارزشمند تشخیص داده شده است، بطوریکه توسعه دهند گان دیگر می توانند آن را در حل مسائل مشابه به کار ببرند. 9/21/2018 Sima Emadi

هر دامنه الگوی خاص خود را نیاز دارد فصل اول مقدمه همانگونه که طراحی شی گرا ادعا می کند که استفاده مجدد از کتابخانه ها و قطعات را افزایش می دهد، ادعا می شود که استفاده از الگوهای طراحی نیز، استفاده مجدد از کتابخانه ها و قطعات را افزایش می دهد.  الگوها تکنیک هایی هستند که افراد زمانی از آنها برای حل مسائل خاص استفاده کردند و به عنوان راه حل های خوب شناخته شده اند. سپس این تکنیک ها مستند سازی شده اند تا توسعه دهندگان هنگام برخورد با مسائل مشابه از این مستندات استفاده کنند و مسائل خود را حل کنند. بعبارتی هر الگوی طراحی براساس اصولی یک طراحی تکراری و مهم را در سیستمهای شی گرا نامگذاری کرده، توضیح داده و ارزیابی می کند. اما الگوهای طراحی تنها بخشی از آنچه که یک طراح خبره می داند را بیان می کند. الگوهای مربوط به برنامه نویسی همروندی، توزیعی یا بلادرنگ را مطرح نمی کند. همچنین ایده ای در رابطه با اینکه واسط کاربر یا یک پایگاه داده نوشته شود را نمی دهد. هر دامنه الگوی خاص خود را نیاز دارد 9/21/2018 Sima Emadi

فصل اول مقدمه (ضرورت استفاده از الگوها) فصل اول مقدمه (ضرورت استفاده از الگوها) به کمک الگوهای طراحی هنگام حل مسائل طراحی، منظور خود را با استفاده از واژگان مشترک بیان می کنیم. الگوهای طراحی ما را به استفاده از طراحی درست شیءگرا هدایت می­کنند چون بر اساس قواعد SOLID بنا نهاده شده­اند. روشی کارا برای توصیف راه حل­های مسائل پیچیده هستند. به راحتی می­توان با سایر اعضای تیم بدون توجه به جزئیات پیاده سازی، تبادل نظر نمود. مستقل از زبان بوده و در هر زبان برنامه نویسی شیءگرا قابل استفاده هستند. دانستن این الگوها مهارت استفاده از زبانهای شی گرا را در طراح افزایش می دهد. 9/21/2018 Sima Emadi

فصل اول مقدمه (سودمندی الگوها) فصل اول مقدمه (سودمندی الگوها) ارزش الگوهای طراحی در این است که آنها راه حل­های امتحان شده­ای هستند، که در کارایی آنها شکی وجود ندارد و اصطلاحاً به آنها Best Practice می­گویند. اگر شما توسعه دهنده باتجربه­ای باشید مطمئنا بارها از آنها استفاده کرده­اید، با آنکه ممکن است حتی اسمشان را نشنیده باشید. اما راه حل­های معجزه آسا نیستند. بلکه باید کاملا مسئله را درک نمود، سپس از الگویی مناسب استفاده نمود همه مسائل به الگوی طراحی نیاز ندارند و تنها زمانی که لازم است، باید استفاده شوند. 9/21/2018 Sima Emadi

فصل اول مقدمه (آنچه که نباید از ”الگوهای طراحی“ انتظار داشت) فصل اول مقدمه (آنچه که نباید از ”الگوهای طراحی“ انتظار داشت) شاه کلید نیستند و هر مشکلی با استفاده از این الگوها حل نخواهد شد. این الگوها هر چند به حل مشکلات پچیده و ساده شدن آنها کمک میکنند، اما استفاده از آنها برای مشکلات ساده می توانند پیچیدگی را افزایش داده و مشکل آفرین باشد. در صورت دست یافتن به راه حلی ساده، شفاف و قابل تعمیم، لزومی به استفاده حتمی از الگوها نیست. 9/21/2018 Sima Emadi

فصل اول مقدمه (عوامل ایجاد الگوهای طراحی) استفاده از شی گرایی در توسعه نرم افزار اغلب روشهای تحلیل و طراحی شی گرا تاکید بسیاری بر استفاده از نمادها در طراحی دارند. تحلیل و طراحی شی گرا متمرکز بر رسم نمودارهای مختلف است طراحی شی گرای خوب نیاز به سالها تجربه دارد بیشترین استفاده مجدد در هنگام طراحی اتفاق می افتد لذا الگوها سبب ارتقای تجرید، انعطاف پذیری، واحدبندی و ظرافت شده و حاوی اطلاعات ارزشمند طراحی هستند ظرافت elegance 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ کریستوف الکساندر می گوید: هر الگو بیانگر مسئله و مشکلی است که بارها رخ داده، همراه با راه حل آن مسئله، که می توان از آن بدون نیاز به یافتن راه حل جدید میلیون ها بار استفاده کند بهترین تعریف الگو «تجریدی از یک شکل عینی که تکرار را در زمینه دلخواه نگاه می دارد» الگو چیزی فراتر از راه حل است و بیانگر این است که مسئله مورد نظر در زمینه خاصی اتفاق می افتد که در آن علاقمندیهای دیگری نیز وجود دارند. در واقع راه حل پیشنهادی یک الگو حاوی نوعی ساختار است که بین علاقمندیهای خاص یا اجبارها توازن برقرار می نماید تا بهترین راه حل برای مسئله در زمینه مورد نظر ارائه شود. 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ هر الگو شامل مجموعه ای از وابستگی ها، ساختارها، تعاملات و قراردادها است هر الگو نام و ساختار طراحی را صریح تعیین می کند و راه حلی نمونه برای مسئله ای در زمینه خاص مطرح می کند. الگوهای طراحی توصیف اشیا ارتباطی و کلاسهایی هستند که برای حل یک مسئله طراحی عمومی در یک زمینه خاص سفارشی شده اند. یک الگوی طراحی جنبه های کلیدی یک ساختار عمومی طراحی را که برای ایجاد یک طراحی قابل استفاده مجدد شی گرا مفید باشد، شناسایی، نامگذاری و تجزیه می کند. 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ یک الگوی خوب کارهای زیر را انجام می دهد: مسئله ای را حل می کند: الگوها راه حلها را نشان می دهند نه راهبرد یا مفاهیم. یک مفهوم اثبات شده است: راه حلهای اثبات شده برای انجام مسئله هستند راه حل مشهود نیست: بهترین الگوها راه حلی غیر مستقیم برای یک مسئله تولید می کنند. یک رابطه را توصیف می کنند: الگوها نه تنها ماژولها را توصیف می کنند بلکه ساختارهای سیستم و مکانیزمها را عمیق تر توصیف می کنند 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ یک الگو 4 عنصر ضروری دارد: Pattern name Problem Solution Consequence 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ نام الگو عبارتی است که الگو را توصیف می کند از نام الگو برای توصیف مسئله طراحی، راه حل آن و نتایجش در یک یا دو جمله استفاده می شود. مزایا: انجام طراحی در سطوح بالاتر تجرید فکر کردن درباره طراحی ها و نحوه ارتباط و موازنه با یکدیگر را ساده تر می کند. افزایش محتویات دیکشنری طراح سخن گفتن در مورد آنها در هر کجا 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ مسئله شرحی از مشکلی که قرار است توسط این الگوی طراحی راه حل آن بیان شود. توصیف کننده زمانی است که الگوها باید استفاده شوند توصیف کننده زمینه، مسائل خاص طراحی و یا ساختار کلاس یا اشیائی است که نشانه های یک طراحی انعطاف پذیر هستند گاهی اوقات یک مسئله لیستی از شرایطی است که قبل از بکارگیری الگو بایستی درنظر گرفته شود. 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ راه حل اجزا طراحی مورد نیاز و ارتباط میان آنها است توصیف کننده عناصر سازنده ی طراحی، روابط، مسئولیتها و همکاریهایشان است قالبی است که در وضعیتهای بسیاری استفاده می شود. یک توصیف انتزاعی از مسئله طراحی و مشخص نمودن ترتیب خاصی از عناصر برای حل مشکل است 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ نتایج نتیجه و موازنه بکارگیری الگوها را از نظر زمان و فضا نشان می دهد. برای ارزیابی پیشنهادات و درک هزینه ها و فوائد بکارگیری الگوها ضروری هستند در بیان نتایج بایستی موازنه بین فضا و زمان را درنظر گرفت از طرفی چون استفاده مجدد معیار اصلی است نتایج یک الگو شامل تاثیر الگو بر روی انعطاف پذیری، توسعه پذیری و قابلیت حمل سیستم است. این نتایج به درک الگو و ارزیابی آنها بطور صریح کمک می کند 9/21/2018 Sima Emadi

الگوی طراحی چیست؟ زمینه چه وقت بایستی از این الگوی طراحی استفاده کرد 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC به منظور ساخت واسط کاربر در الگوها استفاده می شود. سه نوع شی به نامهای model/view/controller دارد Model یک شی کاربرد (application object) است. View نحوه نمایش شی در نمایشگر است و وضعیت مدل را بصورت شفاف منعکس می کند Controller روشی را که واسط کاربر در مقابل ورودی کاربر عکس العمل نشان می دهد را تعریف می کند. 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC Model لایه data را می سازد. هرچیزی که مرتبط به اطلاعات ذخیره شونده هست باید از این لایه بگذرد. View لایه‌ایست که کاربر از طریق آنdata را می‌بیند Controller چسب بین این دو لایه خواهد بود. در این طراحی هر نوع عملگری با استفاده از کارکردش در جای مناسبش قرار می گیرد. 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC MVC مخفف Model-View-Controller بوده و الگوی طراحی نرم افزار می باشد که در دهه ی ۱۹۷۰ معرفی شد. الگوی MVC باعث جدایی برخی از مفاهیم شد یعنی model و منطق  controller از رابط کاربری (view) جدا شدند. در نتیجه نگهداری و آزمودن اپلیکیشن سهل و ساده شد. الگوی طراحی MVC اپلیکیشن را به سه حوزه ی اصلی تقسیم می کندModel، View و Controller 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC ۱- Model Model شامل مجموعه ای از کلاس ها می باشد که منطق کار را مشخص می کنند؛ به این معنا که model کار و داده ها به عملیات که همان data model می باشد دسترسی دارند. Model همچنین قوانین کار برای داده ها را نیز مشخص می کند؛ به عبارت دیگر برای داده مشخص می کند که چگونه تغییر و دستکاری شود. ۲- View View نشان دهنده ی کامپوننت های UI از قبیل CSS، jQuery، html و غیره می باشد. View تنها مسئول نمایش داده هایی می باشد که از به عنوان یک نتیجه از سمت controller دریافت شود. View همچنین model را به UI تبدیل می کند. ۳- Controller Controller مسئول پردازش درخواست های ورودی می باشد که ورودی های کابر را از طریق View دریافت کرده و سپس داده های کاربر را به کمک Model پردازش می کند و نتیجه را مجددا به View باز می گرداند. معمولا Controller به عنوان هماهنگ کننده ای بین View و Model عمل می کند. 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC الگوی MVC با ایجاد پروتکل subscribe/notify بین model و view آنها را تجزیه می کند. با تغییر داده های مدل، model بایستی view های مربوطه را مطلع سازد View نیز برای بروز رسانی خودش فرصتی را کسب می نماید. مزیت این روش داشتن چندین view برای یک مدل به منظور نمایشهای مختلف است. ایجاد view های جدید برای یک مدل بدون نوشتن مجدد آنها 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC gesture اشاره ،حرکت ،اشارات و حرکات در موقع سخن گفتن ،وضع ،رفتار،ژست ،قيافه ،ادا -------------------------------------------------------------------------------- Mouse Gestureقابليت جالبه که يه سري کار رو برنامه با حرکات ماوس شما انجام ميده. مثلا اگه دکمه وسط ماوس رو نگه داريد و ماوس رو به سمت پايين بيارين، برنامه Minimize ميشه. اگه به بالا ببرين Maximize ميشه 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC gesture اشاره ،حرکت ،اشارات و حرکات در موقع سخن گفتن ،وضع ،رفتار،ژست ،قيافه ،ادا -------------------------------------------------------------------------------- Mouse Gestureقابليت جالبه که يه سري کار رو برنامه با حرکات ماوس شما انجام ميده. مثلا اگه دکمه وسط ماوس رو نگه داريد و ماوس رو به سمت پايين بيارين، برنامه Minimize ميشه. اگه به بالا ببرين Maximize ميشه 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC با تغییر مقادیر داده model با view ارتباط برقرار می کند . View نیز برای دسترسی به مقادیر با model ارتباط برقرار می کند A=10% B=40% C=30% D=20% Application data A B C D Relative Percentages Y 10 40 30 20 X 15 35 35 15 Z 10 40 30 20 A B C D Change notification Requests, modifications Model 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC این روش اشیا را بگونه ای تجزیه می کند که تغییر در یکی بقیه اشیا را تحت تاثیر قرار می دهد بدون اینکه شی تغییر یافته نیازی به دانستن جزئیات اشیا دیگر داشته باشد. در این الگو viewها می توانند تودر تو باشند. مثل یک کنترل پنلی از دکمه های متفاوت یا یک object inspector در یک debugger . MVC با استفاده از کلاسهای composite view از view های تودرتو پشتیبانی می کند. کاربرد دیگر MVC این است که اجازه تغییر نحوه پاسخ view را به ورودیهای کاربر تغییر می دهد. MVC مکانیزمهای پاسخ را در یک شی کنترلی بسته بندی می کند 9/21/2018 Sima Emadi

الگوهای طراحی در smalltalk MVC View به منظور پیاده سازی استراتژی پاسخ خاص از یک instance از زیرکلاس کنترلر استفاده می کند. رابطه بین view-controller نمونه ای از الگوی strategy است. Strategy شیئی است که یک الگوریتم را نشان می دهد. MVC از الگوهای طراحی دیگری مثل factory method جهت مشخص نمودن کلاس کنترلی پیش فرض برای view یا از الگوی decorator جهت اضافه نمودن scrolling به یک view استفاده می کند. اما روابط اصلی در MVC توسط الگوهای observer، composite و strategy ایجاد می شوند 9/21/2018 Sima Emadi

MVC Design Pattern Examples Observer Pattern: decoupling of model from view changes to one object can affect multiple views, without requiring object to know details of view Composite Pattern: nesting of views class hierarchy in which some subclasses define primitive objects and other classes define composite objects that assemble primitives into more complex objects Strategy Pattern: view-controller relationship allows controller to replaced statically or dynamically 9/21/2018 Sima Emadi

MVP الگوی MVP این الگو مشابه با الگوی MVC می باشد که در آن controller با یک presenter جایگزین شده است. این الگوی طراحی یک اپلیکیشن را به سه قسمت تقسیم می کند Model، View و Presenter فقط لایه Presenter کمی شبیه ViewModel عمل می کند. تفاوتی که با MVVM دارد در این است که در این روش بر عکس MVVM ارتباط بین Presenter و View به صورت یک به یک می باشد. 9/21/2018 Sima Emadi

MVP 9/21/2018 Sima Emadi

MVP الگوی MVP 9/21/2018 Sima Emadi

MVP الگوی MVP  ۱- Model Model شامل مجموعه ای از کلاس ها می باشد که منطق کار را مشخص می کنند؛ Model همچنین قوانین کار برای داده ها را نیز مشخص می کند؛ به عبارت دیگر برای داده مشخص می کند که چگونه تغییر و دستکاری شود. ۲- View View نشان دهنده ی کامپوننت های UI از قبیل CSS، jQuery، html و غیره می باشد. View تنها مسئول نمایش داده هایی می باشد که از به عنوان یک نتیجه از سمت controller دریافت شود. View همچنین model را به UI تبدیل می کند. 9/21/2018 Sima Emadi

MVP الگوی MVP ۳- Presenter Presenter به نیابت از View مسئول مدیریت تمام رویداد های UI می باشد که ورودی کاربران را از طریق View دریافت کرده و سپس آنها را با کمک Model پردازش می کند و نتایج را به View بازمیگرداند. بر خلاف view و controller، view و presenter کاملا از یکدیگر جدا بوده و از طریق یک رابط با یکدیگر ارتباط برقرا می کنند. همچنین presenter مانند controller رفت و آمد درخواست های ورودی را مدیریت نمی کند. این الگو نیز توسط اپلیکیشن های ASP.NET Web Form که نیاز به ایجاد آزمون های واحد و خودکار برای صفحات دارای کد خود دارند نیز استفاده می شود. در اپلیکیشن های windows form نیز استفاده می شود. 9/21/2018 Sima Emadi

MVP الگوی MVP نکات کلیدی در مورد الگوی MVP: کاربر با view تعامل می کند رابطه ی یک-به-یک بین View و Presenter وجود دارد که یعنی یک View تنها به یک Presenter و نه بیشتر، map شده است View دارای رفرنسی برای Presenter می باشد اما برای Model رفرنسی ندارد رابطه ی دو طرفه بین View و Controller ایجاد می کند. 9/21/2018 Sima Emadi

MVVM طراحی MVVM اولین بار توسطMicrosoft ارایه شد. در ساختار این طراحی Model و View تفاوتی با MVC ندارد. VM یا ViewModel همچون Controller لایه نازکیست بین Model و View اما تفاوت هایش عبارت است از: ارتباط دو‌طرفه با View     ViewModel ارایه کننده View است. یعنی هر فیلد در ViewModel بیشتر برابر با View است و به همین علت از Model دورتر است 9/21/2018 Sima Emadi

MVVM MVVM مخفف Model-View-View Model می باشد. این الگو از data binding دو سویه بین view و View model پشتیبانی می کند. الگوی MVVM انتشار خودکار تغییرات را در حالت view model به View را میسر می کند. معمولا view model از الگوی observer برای اطلاع رسانی تغییرات ایجاد شده در view model به model استفاده می کند. 9/21/2018 Sima Emadi

MVVM 9/21/2018 Sima Emadi

MVVM   ۱- Model Model شامل مجموعه ای از کلاس ها می باشد که منطق کار را مشخص می کنند؛ Model همچنین قوانین کار برای داده ها را نیز مشخص می کند؛ به عبارت دیگر برای داده مشخص می کند که چگونه تغییر و دستکاری شود. ۲- View View نشان دهنده ی کامپوننت های UI از قبیل CSS، jQuery، html و غیره می باشد. View تنها مسئول نمایش داده هایی می باشد که از به عنوان یک نتیجه از سمت controller دریافت شود. View همچنین model را به UI تبدیل می کند. ۳- View Model View Model مسئول نمایش متد ها، فرامین و دیگر خصوصیت هایی است که به حفظ حالت view کمک کرده، model را به عنوان نتیجه اعمال انجام شده بر روی view تغییر داده و رویداد ها را در view ایجاد می کند. 9/21/2018 Sima Emadi

MVVM       هر View ی مستقیماً به یک ViewModel مقید(bind) می‌شود و در نتیجه تغیرات مربوط به View به صورت لحظه‌ای درViewModel دیده می‌شود و از طرفی تغییرات برعکس هم باعث render مجدد View می شود.   معمولاً برای هر View فقط یک ViewModel وجود دارد. این ارتباط یک به N می باشد.     Model و View فقط از طریق ViewModel ارتباط دارند. 9/21/2018 Sima Emadi

MVVM نقاط کلیدی در مورد الگوی MVVM کاربر با View تعامل می کند رابطه ی چند-به-یک بین View و ViewModel وجود دارد. به عبارت دیگر چند View می تواند به یک ViewModel ، map شود. View دارای یک رفرنس به ViewModel می باشد اما View Model هیچ اطلاعاتی در مورد view ندارد از data binding دوسویه بین View و ViewModel پشتیبانی می کند. 9/21/2018 Sima Emadi

MOVE : MVC is dead, it's time to MOVE on. در این طراحی که شباهت زیادی با MVP دارد تفاوتی که وجود دارد Operation جای Presenter گرفته است. و از طرفی Model با استفاده از Event می‌تواند View را دوباره Render کند. یعنی دیگر نیازی نیست که Model به لایه ارتباطی بگوید که فلان data ی من عوض شده در عوض به view می گویید. در این روش سیستم بر اساس Event و Change call کار می‌کند. 9/21/2018 Sima Emadi

MOVE Models encapsulate everything that your application knows. Operations encapsulate everything that your application does. Views mediate between your application and the user. Events are used to join all these components together safely. 9/21/2018 Sima Emadi

MOVE views are allowed to listen to events emitted by models, and operations are allowed to change models, but models should not refer to either views or operations. 9/21/2018 Sima Emadi

9/21/2018 Sima Emadi

قالب مستند سازی برای الگوهای طراحی یا توصیف الگوها یک نام خوب و مفید برای الگو زيرا ماهيت الگو را مشخص مي كند نام الگو یک جمله کوتاه و مختصر درباره كاري که الگو انجام می دهد (تعریف مسئله و راه حل به صورت مختصر و مفید) هدف قصد و نیت (intent) نامهای دیگری که الگو با آن شناخته می شود نام مستعار یک نمایش گرافیکی از الگو با استفاده از نمادهاي مبتني بر OMT ساختار (structure) کلاسها و اشیایی که در الگو شرکت دارند و مسئوليتهايشان را نشان مي دهد. اجزا تشکیل دهنده (participant) يا شركا چگونه اجزای تشکیل دهنده با هم همکاری می کنند تا وظایفشان را انجام دهند همکاریها (collaboration) نتایج استفاده از الگوی موردنظر. موازنه (trade off) حاصل از استفاده اين الگو چيست؟ نتایج (consequences) تکنیکهایی برای پیاده سازی الگوی مورد نظر پیاده سازی قالب مستند سازی برای الگوهای طراحی یا توصیف الگوها 9/21/2018 Sima Emadi

كاربردپذيري (applicability) سناريويي كه مسائل طراحي را توضيح مي دهد. چگونگی حل مسئله را توسط ساختار كلاسها و اشيا در الگو نشان مي دهد انگيزه (motivation ) وضعيتهايي كه اين الگو مي تواند بكار رود چيست؟ چه نمونه هایی از طراحی های ضعیف وجود دارد که الگو آن را نشان می دهد كاربردپذيري (applicability) بخشهايي از كد كه چگونگي پياده سازي الگو را در C++ نشان مي دهد كد نمونه استفاده هاي شناخته شده از اين الگو و كاربرد آن در سيستمهاي موجود را نشان مي دهد. استفاده شناخته شده ارتباطات پويا و ايستاي بين اين الگو و ديگر الگوها را در همان زبان يا سيستم نشان ميدهد. الگوهاي مرتبط 9/21/2018 Sima Emadi

The Catalog of Design Patterns Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Bridge Decouple an abstraction from its implementation so that the two can vary independently. 9/21/2018 Sima Emadi

The Catalog of Design Patterns Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations. Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. 9/21/2018 Sima Emadi

The Catalog of Design Patterns Composite Compose objects into tree structures to represent part- whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Facade Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. 9/21/2018 Sima Emadi

The Catalog of Design Patterns Factory Method Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Flyweight Use sharing to support large numbers of fine-grained objects efficiently. Interpreter Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. 9/21/2018 Sima Emadi

The Catalog of Design Patterns Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Mediator Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Memento Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. 9/21/2018 Sima Emadi

The Catalog of Design Patterns Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Proxy Provide a surrogate or placeholder for another object to control access to it. Surrogate جایگزین Placeholder جایگاه 9/21/2018 Sima Emadi

The Catalog of Design Patterns Singleton Ensure a class only has one instance, and provide a global point of access to it. State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Alter تغییر 9/21/2018 Sima Emadi

The Catalog of Design Patterns Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm 's structure. Visitor Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. 9/21/2018 Sima Emadi

The Catalog of Design Patterns 9/21/2018 Sima Emadi

Design patterns vary in their granularity and level of abstraction. Organizing the catalog Design patterns vary in their granularity and level of abstraction. We classify design patterns by two criteria Purpose scope 9/21/2018 Sima Emadi

Organizing the catalog Scope: domain over which a pattern applies Purpose: reflects what a pattern does 9/21/2018 Sima Emadi

Organizing the catalog Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavior al patterns characterize the ways in which classes or objects interact and distribute responsibility. 9/21/2018 Sima Emadi

Organizing the catalog Class patterns Deal with relationships between classes and their subclasses Relationships established through inheritance, so they are fixed at compile time (static) Object patterns Deal with object relationships Relationships can be changed at runtime (dynamic) Almost all patterns use inheritance to some extent. So the only patterns labeled "class patterns" are those that focus on class relationships. Note that most patterns are in the Object scope. 9/21/2018 Sima Emadi

Six types of design patterns Creational class patterns defer some part of object creation to subclasses Creational object patterns defer some part of object creation to another object Structural class patterns use inheritance to compose classes Structural object patterns describe ways to assemble objects Behavioral class patterns use inheritance to describe algorithms and flow of control 6. Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone 9/21/2018 Sima Emadi

Organizing the catalog There are other ways to organize the patterns. Some patterns are often used together. For example, Composite is often used with Iterator Visitor. Some patterns are alternatives: Prototype is often an alternative to Abstract Factory. Some patterns result in similar designs even though the patterns have different intents. For example, the structure diagrams of Composite and Decorator are similar. Patterns which reference one another Additional ways to organize design patterns 9/21/2018 Sima Emadi

کاتالوگ الگوهای طراحی Yet another way to organize design patterns is according to how they reference each other in their "Related Patterns" sections. 9/21/2018 Sima Emadi

کاتالوگ الگوهای طراحی 9/21/2018 Sima Emadi

Review of some OO concepts Encapsulation: Object packages both data and procedures (called methods or operations). It performs an operation when it receives request (or messages) from a client. Request are the only way to get an object to do an operation. Operations are the only way to change object’s internal data. So the internal state of an object is said to be encapsulated. 9/21/2018 Sima Emadi

Review cont... Operation signature (name , objects for parameters, returned objects) The set of all signatures defined by an object’s operations is called the interface to the object. Type: a name denoting a particular interface. (e.g type “window”, if it accepts all requests for interface “window”). An object may have many types and many object can share the same type. Subtype, super type : subtype inheriting its super type 9/21/2018 Sima Emadi

Review cont.. Dynamic binding: Run-time association of a request to an object and of it’s operations. (Different objects that support identical requests may have different implementations of the operations.) Polymorphism: Dynamic binding let’s you substitute objects with similar interfaces at run-time. This in known as polymorphism, a key concept in OO systems. 9/21/2018 Sima Emadi

Review cont.. We use three different diagrammatic notations: 1. A class diagram depicts classes, their structure, and the static relationships between them. 2. An object diagram depicts a particular object structure at run-time. 3. An interaction diagram shows the flow of requests between objects 9/21/2018 Sima Emadi

Review cont.. In some design patterns it's helpful to see where client classes reference Participant classes. When a pattern includes a Client class as one of its participants (meaning the client has a responsibility in the pattern), the Client appears as an ordinary class. This is true in Flyweight ( 195) , for example. 9/21/2018 Sima Emadi

Review cont.. When the pattern does not include a Client participant (i.e., clients have no responsibilities in the pattern), but including it nevertheless clarifies which pattern participants interact with clients, then the Client class is shown in gray. An example is Proxy (207 ). A gray Client also makes it clear that we haven't accidentally omitted the Client from the Participants discussion. 9/21/2018 Sima Emadi

Review cont.. The OMT notation for class inheritance is a triangle connecting a subclass (LineShape in the figure) to its parent class (Shape). An object reference representing a part-of or aggregation relationship is indicated by an arrow headed line with a diamond at the base. The arrow points to the class that is aggregated (e. g. , Shape). 9/21/2018 Sima Emadi

Review cont.. An arrow headed line without the diamond denotes acquaintance (e.g. , a LineShape keeps a reference to a Color object, which other shapes may share). A name for the reference may appear near the base to distinguish it from other references 9/21/2018 Sima Emadi

Review cont.. Another useful thing to show is which classes instantiate which others. We use a dashed arrowheaded line to indicate this, since OMT doesn't support it. We call this the "creates" relationship. The arrow points to the class that's instantiated. In this figure, CreationTool creates LineShape objects. 9/21/2018 Sima Emadi

Review cont.. OMT also defines a filled circle to mean "more than one." When the circle appears at the head of a reference, it means multiple objects are being referenced or aggregated. This figure shows that Drawing aggregates multiple objects of type Shape 9/21/2018 Sima Emadi

Review cont.. Object Diagram An object diagram shows instances exclusively. It provides a snapshot of the objects in a design pattern. The objects are named "aSomething", where Something is the class of the object. Our symbol for an object (modified slightly from standard OMT ) is a rounded box with a line separating the object name from any object references 9/21/2018 Sima Emadi

Class inheritance versus Interface inheritance Review cont.. Class inheritance versus Interface inheritance Difference between an object’s class and it’s type : type only refers to it’s interface, objects of different classes can have the same type Class inheritance is a mechanism for code and representation sharing. Interface inheritance describes when an object can be used in place of another. C++ use classes to specify both type and it’s implementation. So it does not distinguish the difference. Java, recognizes the difference. 9/21/2018 Sima Emadi

Review cont.. Object implementation Object instantiation: object are created by instantiating a class. (allocating memory to hold instance variables) Class inheritance: Subclass inheriting from a parent class Abstract class, concrete class, abstract operations Overriding an operation defined by parent class. Mix in class, a class that is intended to provide optional interfaces to other classes and not to be instantiated. 9/21/2018 Sima Emadi

Review cont.. Aggregation and Association Aggregation means on object owns another object (having or being part of) It implies that an aggregate object and its owner have identical lifetimes. Association (acquaintance, using ) means that object knows another object. They use each others operations but they are not responsible for each other. They have different lifetimes 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems Here are several of problems and how design patterns solve them. Finding Appropriate Objects Determining Object Granularity Specifying Object Interfaces Specifying Object Implementations Class versus Interface Inheritance Programming to an Interface, not an Implementation Putting Reuse Mechanisms to Work Inheritance versus Composition Delegation 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Here are several of problems and how design patterns solve them. Inheritance versus Parameterized Types Relating Run-Time and Compile-Time Structures Designing for Change Application Programs Toolkits Frameworks 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Finding Appropriate Objects The hard part about OO design is decomposing a system into objects. Why? many factors are involved: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, etc. Many objects come from the analysis model. But we often end up with classes that has no counterpart in the real world. Strict modeling of the world leads to a design that reflect today’s need and not necessarily future. Abstraction is a way to treat objects that do not have a physical counterpart. Design patterns help you identify less obvious abstractions and objects that can capture them. Counterpart همکار قرین نقطه مقابل 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Finding Appropriate Objects The Strategy pattern describes how to implement interchangeable families of algorithms. The State pattern represents each state of an entity as an object. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Determining Granularity How do we decide what should be an object? In what granularity? Design Patterns address this issue as well. Façade pattern describe how to present complete subsystems as objects. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Determining Granularity Flyweight pattern describes how to support huge numbers of objects at the finest granularities. Other design patterns describe specific ways of decomposing an object into smaller objects. Abstract Factory and Builder yield objects whose only responsibilities are creating other objects. Visitor and Command yield objects whose only responsibilities are to implement a request on another object or group of objects. Yield ,واگذار کردن ثمر دادن بازدهی 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying object interfaces What should be the messages? Design patterns help defining interfaces by determining the type of data that gets sent across interfaces. Memento pattern for example defines two interfaces: a restricted one that hold and copy mementos and one privileged one that only original object can use to store and retrieve state. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying object interfaces A type is a name used to denote a particular interface. We speak of an object as having the type "Window" if it accepts all requests for the operations defined in the interface named "Window." An object may have many types, and widely different objects can share a type. Part of an object's interface may be characterized by one type, and other parts by other types. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying object interfaces Interfaces can contain other interfaces as subsets. We say that a type is a subtype of another if its interface contains the interface of its supertype. Often we speak of a subtype inheriting the interface of its supertype. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying object interfaces The run-time association of a request to an object and one of its operations is known as dynamic binding. Dynamic binding means that issuing a request doesn't commit you to a particular implementation until run-time. Moreover, dynamic binding lets you substitute objects that have identical interfaces for each other at run-time. This substitutability is known as polymorphism. Polymorphism simplifies the definitions of clients, decouples objects from each other, and lets them vary their relationships to each other at run-time. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying object interfaces Design patterns also specify relationships between interfaces. In particular, they often require some classes to have similar interfaces, or they place constraints on the interfaces of some classes. For example, both Decorator and Proxy require the interfaces of Decorator and Proxy objects to be identical to the decorated and proxied objects. In Visitor, the Visitor interface must reflect all classes of objects that visitors can visit. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations An object's implementation is defined by its class. The class specifies the object's internal data and representation and defines the operations the object can perform. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) Objects are created by instantiating a class. The object is said to be an instance of the class. A dashed arrowhead line indicates a class that instantiates objects of another class. The arrow points to the class of the instantiated objects. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) New classes can be defined in terms of existing classes using class inheritance. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) An abstract class is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn't implement are called abstract operations. Classes that aren't abstract are called concrete classes. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) Subclasses can refine and redefine behaviors of their parent classes. More specifically, a class may override an operation defined by its parent class. Overriding gives subclasses a chance to handle requests instead of their parent classes. Class inheritance lets you define classes simply by extending other classes, making it easy to define families of objects having related functionality. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) Abstract class 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Specifying Object Implementations (continue) A mixin class is a class that 's intended to provide an optional interface or functionality to other classes. It's similar to an abstract class in that it's not intended to be instantiated. Mixin classes require multiple inheritance: 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Class versus Interface Inheritance It's important to understand the difference between an object's class and its type. An object's class defines how the object is implemented. The class defines the object's internal state and the implementation of its operations. An object's type only refers to its interface—the set of requests to which it can respond. An object can have many types, and objects of different classes can have the same type. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Class versus Interface Inheritance there's a close relationship between class and type. Because a class defines the operations an object can perform, it also defines the object's type. When we say that an object is an instance of a class, we imply that the object supports the interface defined by the class. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Class versus Interface Inheritance difference between class inheritance and interface inheritance (or subtyping). Class inheritance defines an object's implementation in terms of another object's implementation. In short, it's a mechanism for code and representation sharing. interface inheritance (or subtyping) describes when an object can be used in place of another. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Class versus Interface Inheritance Many of the design patterns depend on this distinction. For example, objects in a Chain of Responsibility must have a common type, but usually they don't share a common implementation. In the Composite pattern, Component defines a common interface, but Composite often defines a common implementation. Command, Observer, State, and Strategy are often implemented with abstract classes that are pure interfaces. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Programming to an interface, not an implementation Class inheritance is basically just a mechanism for extending an application's functionality by reusing functionality in parent classes. Class inheritance gives the ability to define new objects in terms of an old one (get free implementation for most of what you need). However, implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Programming to an interface, not an implementation Why? Because polymorphism depends on it. Another purpose is getting identical interfaces by inhering from an abstract class (polymorphism depends on it). 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Programming to an interface, not an implementation all classes derived from an abstract class simply override interfaces and therefore they can all respond to the requests to the abstract class (i.e. they are all subtypes) This implies that a subclass merely adds or overrides operations and does not hide operations of the parent class. All subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Programming to an interface, not an implementation Two benefits: 1- clients remain unaware of the specific type of objects they use. 2- classes remain unaware of the classes that implement these objects (in Short clients need only know the abstract classes) 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Programming to an interface, not an implementation This leads us to the first good design principle: Program to an Interface, not to an implementation Consequences: Don’t declare variables to be instances of a concrete classes, instead commit only to interfaces of an abstract class. -Creational patterns ensure that your system is written in terms of interfaces, not implementations. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Most people can understand concepts like objects, interfaces, classes, and inheritance. The challenge lies in applying them to build flexible, reusable software, and design patterns can show you how. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Inheritance versus composition The two most common techniques for reusing functionality in object- oriented systems are class inheritance and object composition. class inheritance lets you define the implementation of one class in terms of another's. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Inheritance versus composition - White-box reuse: Reuse by subclassing (The internals of parent classes visible to subclasses) - An alternative to class inheritance to get more complex functionality is object composition - object Composition requires that objects being composed to have well- defined interfaces. - Black-box reuse: Reuse by composition (no internals of objects are visible). 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work This style of reuse is called black-box reuse, because no internal details of objects are visible. Objects appear only as "black boxes." 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: -Ad: Class inheritance is defined statically at compile time, easy to use since it has the language support. Easy to modify implementation by overriding some operations: - Dis: Can not change inherited implementation at runtime (its defined at compile time). worse: Inheritance breaks encapsulation. Any change to parent implementation will force subclasses to change. Implementation dependency makes reuse of subclasses very limited, as any change to subclasses need to change parents. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: Implementation dependencies can cause problems when you're trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability. One cure for this is to inherit only from abstract classes, since they usually provide little or no implementation. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work advantages and disadvantages of composition defined dynamically at run-time through objects acquiring references to other objects. requires carefully designed interfaces. Moreover, because an object's implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. classes and class hierarchies will remain small a design based on object composition will have more objects (if fewer classes), and the system's behavior will depend on their interrelationships instead of being defined in one class. Acquiring بدست آوردن اندوختن 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: - We do not break encapsulation because objects are accessed solely through interfaces (but that means some effort on good interface design) - Any object can be replaces with another at runtime as long as it has same type. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: -That leads us to our second principle of object-oriented design: Favor object composition over class inheritance. Favor : توجه کردن التفات کردن طرفداری کردن 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: Consequences: Helps keep each class encapsulated and focused on one task. Classes and class hierarchies will remain small and more manageable. A design with composition will have more objects and system behavior will depend on their interrelationship rather than defined in one class. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: Note: - Inheritance and composition work together - Designers tend to over use inheritance to achieve new functionality - Designs are made more reusable and simpler by depending more on object composition. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: Ideally, you shouldn't have to create new components to achieve reuse. You should be able to get all the functionality you need just by assembling existing components through object composition. But this is rarely the case, because the set of available components is never quite rich enough in practice. Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Putting Reuse Mechanisms to Work Advantages and disadvantages of both: Nevertheless, our experience is that designers overuse inheritance as a reuse technique, and designs are often made more reusable (and simpler) by depending more on object composition. You'll see object composition applied again and again in the design patterns. 9/21/2018 Sima Emadi

This diagram shows how the fly and sound behaviour of an animal can be designed in a flexible way by using the composition over inheritance design principle 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: A way to making composition powerful for reuse. A delegate is an object that acts on behalf of, or in coordination with, another object when that object encounters an event in a program. - Two objects are involved in handling a request: one object receives the request, and delegates the request to be handled by its delegate. (the receiver passes a reference to itself to the delegate) This is analogous to subclasses deferring requests to parent classes. Delegation: نمایندگی وکالت 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: But with inheritance, an inherited operation can always refer to the receiving object through the this member variable in C++ and self in Smalltalk . To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: Example : Window and Rectangle objects (instead of using inheritance, instead of window being a rectangle, it can have a rectangle( For example, instead of making class Window a subclass of Rectangle (because windows happen to be rectangular), the Window class might reuse the behavior of Rectangle by keeping a Rectangle instance variable and delegating Rectangle-specific behavior to it. In other words, instead of a Window being a Rectangle, it would have a Rectangle. Window must now forward requests to its Rectangle instance explicitly, whereas before it would have inherited those operations. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: A plain arrowhead line indicates that a class keeps a reference to an instance of another class. The reference has an optional name, "rectangle" in this case. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: The main advantage of delegation is that it makes it easy to compose behaviors at run-time (e.g window can become circle instead of rectangle, by simply replacing the instances if they are the same type) Disadvantage: Dynamic, highly parameterized software is hard to read and understand. There are also run-time inefficiencies, but the human inefficiencies are more important in the long run. Delegation is a good design choice when it simplifies more that it complicates. - Delegation works best if it’s used in highly stylized ways – that is in standard patterns (State, Strategy and visitor patterns rely on delegation). 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: Several design patterns use delegation. The State, Strategy and Visitor patterns depend on it. In the State pattern, an object delegates requests to a State object that represents its current state. In the Strategy pattern, an object delegates a specific request to an object that represents a strategy for carrying out the request. An object will only have one state, but it can have many strategies for different requests. The purpose of both patterns is to change the behavior of an object by changing the objects to which it delegates requests. In Visitor, the operation that gets performed on each element of an object structure is always delegated to the Visit or object. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: Other patterns use delegation less heavily. Mediator introduces an object to mediate communication between other objects. Sometimes the Mediator object implements operations simply by forwarding them to the other objects; other times it passes along a reference to itself and thus uses true delegation. Chain of Responsibility handles requests by forwarding them from one object to another along a chain o f objects. Sometimes this request carries with it a reference to the original object receiving the request, in which case the pattern is using delegation. Bridge decouples an abstraction from its implementation. If the abstraction and a particular implementation are closely matched, then the abstraction may simply delegate operations to that implementation. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Delegation: Delegation is an extreme example of object composition. It shows that you can always replace inheritance with object composition as a mechanism for code reuse. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Inheritance versus Parameterized Types: Parameterized Type: another technique for reuse also known as Templates (C++, Java). Let you define a type without specifying other types it uses. The unspecified types are supplied as parameters at the point of use. (example : a list class can be parameterized by the type of elements it contains) (Template Method pattern use this technique) Parameterized types give us a third way (in addition to class inheritance and object composition) to compose behavior in object-oriented systems. Many designs can be implemented using any of these three techniques . 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Inheritance versus Parameterized Types: To parameterize a sorting routine by the operation it uses to compare elements, we could make the comparison an operation implemented by subclasses (an application of Template Method 2. the responsibility of an object that 's passed to the sorting routine (Strategy), or 3. an argument of a C++ template or Ada generic that specifies the name of the function to call to compare the elements. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Inheritance versus Parameterized Types: Important differences: Object composition let you change the behavior at run time. Neither inheritance nor parameterized types can change at runtime. but it also requires indirection and can be less efficient. Inheritance provide default implementation for operations. Parameterized types let you change the types that a class can use. Which approach is best depends on your design and implementation constraints. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: Basically no resemblance in OO programs. Trying to understand run-time behavior from static code is like to understand an ecosystem from the taxonomy of plants and animals Code won’t reveal everything about how the system will work. The system run-time behavior must be imposed by designer than by language. Resemblance مقایسه شباهت همانندی 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: Design patterns help to impose the behavior at run-time. Composite and Decorator patterns are especially useful for building complex run-time structures. In general run-time structures aren’t clear from code unless you understand the pattern. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times. Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes. Acquaintance آشنایی سابقه آگاهی در ++C رابطه تجمع مي تواند با تعريف متغيرهاي member که نمونه هاي واقعي هستند پياده سازي شود. ولي متداول تر اين است که آنها را بصورت اشاره گرها يا ارجاعاتي به نمونه ها تعريف کرد. همچنين در اين زبان رابطه آشنايي را مي توان به توسط اشاره گرها يا ارجاعات پياده سازي کرد. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called "association“ or the "using" relationship. Acquainted objects may request operations of each other, but they aren't responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: Aggregation relationships tend to be fewer and more permanent than acquaintance. Acquaintances, are made and remade more frequently, sometimes existing only for the duration of an operation. Acquaintances are more dynamic as well, making them more difficult to discern in the source code. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Run-time and Compile-time Structures: With such disparity between a program's run-time and compile-time structures, it's clear that code won't reveal everything about how a system will work. The system's run-time structure must be imposed more by the designer than the language. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Designing for Change: A design that does not take change into account risks a major redesign in the future. Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of the other aspects, making system more robust to a particular type of change. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Designing for Change: Common causes of change that are addressed by design pattern : 1- Creating an object by specifying a class explicitly (committing to an implementation not to an interface) - solution create an object indirectly; subject of Abstract Factory, Factory Method, Prototype patterns Commit متعهد نمودن به انجام اموری 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Designing for Change: 2- Dependence on specific operations. (committing to one way of responding to a request) - solution: avoid hard-coded request; Chain of responsibility, Command patterns 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Designing for Change: 3- Dependence on hardware and software platform. porting problem from on platform to the other, different OS or different Hardware Solution: Design with no (limited) platform dependencies; Abstract factory and Bridge patterns 4- Dependence on object representations or implementations Solution: Hide this information from clients; Abstract Factory, Bridge, Memento, Proxy patterns 5- Algorithmic dependencies Solution: Algorithms must be isolated; Strategy, Builder, Iterator, Visitor and Template Method 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Designing for Change: 6- Tight coupling – Changes in one class requires changes in many other. Solution: Loose coupling, abstract coupling and layering; Abstract Factory, Bridge, Chain of Responsibility, Command, Façade, Mediator, Observer 7- Extending functionality by subclassing Solution: Object Composition and delegation; Composite, Decorator, Observer, Bridge, … 8- Inability to change classes (no access to source ,commercial class library), Adapter, Decorator, Visitor Conveniently به راحتی 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Application Programs: If you're building an application program such as a document editor or spreadsheet, then internal reuse, maintainability, and extension are high priorities. Internal reuse ensures that you don't design and implement any more than you have to. Design patterns that reduce dependencies can increase internal reuse. Looser coupling boosts the likelihood that one class of object can cooperate with several others. Boost بالابردن زیاد کردن کمک کردن Likelihood احتمال 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Application Programs: For example, when you eliminate dependencies on specific operations by isolating and encapsulating each operation, you make it easier to reuse an operation in different contexts. The same thing can happen when you remove algorithmic and representational dependencies too. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Application Programs: Design patterns also make an application more maintainable when they' re used to limit platform dependencies and to layer a system. They enhance extensibility by showing you how to extend class hierarchies and how to exploit object composition. Reduced coupling also enhances extensibility. Extending a class in isolation is easier if the class doesn't depend on lots of other classes. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Toolkits: Often an application will incorporate classes from one or more libraries of predefined classes called toolkits. A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality. An example of a toolkit is a set of collection classes for lists, associative tables, stacks, and the like. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Toolkits: Toolkits don't impose a particular design on your application; They just provide functionality that can help your application do its job. They let you as an implementer avoid recoding common functionality. Toolkits emphasize code reuse. They are the object-oriented equivalent of subroutine libraries. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Toolkits: Toolkit design is arguably harder than application design, because toolkits have to work in many applications to be useful. Moreover, the toolkit writer isn't in a position to know what those applications will be or their special needs. That makes it all the more important to avoid assumptions and dependencies that can limit the toolkit's flexibility and consequently its applicability and effectiveness. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: Framework is a set of cooperating classes that make up a reusable design for a specific class of software. It usually contains concrete classes that can be used as is. It’s a pre- determined architecture for a particular application 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately. Reuse on this level leads to an inversion of control between the application and the software on which it's based. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: When you use a toolkit (or a conventional subroutine library for that matter), you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls. You'll have to write operations with particular names and calling conventions, but that reduces the design decisions you have to make. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent to their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you. If applications are hard to design, and toolkits are harder, then frameworks are hardest of all. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: Furthermore, because applications are so dependent on the framework for their design, they are particularly sensitive to changes in framework interfaces. As a framework evolves, applications have to evolve with it. That makes loose coupling all the more important; otherwise even a minor change to the framework will have major repercussions. 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: The design issues just discussed are most critical to framework design. A framework that addresses them using design patterns is far more likely to achieve high levels of design and code reuse than one that doesn't. Mature frameworks usually incorporate several design patterns. The patterns help make the framework's architecture suitable to many different applications without redesign. Mature کامل و تکمیل کردن 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: Because patterns and frameworks have some similarities, people often wonder how or even if they differ. They are different in three major ways( Patterns and Frameworks are different): 1- Design patterns are more abstract than framework 2- Design patterns are smaller architectural elements, a typical framework uses several patterns 3- Design patterns are less specialized 9/21/2018 Sima Emadi

How Design Patterns Solve Design problems (continue) Framework and patterns: Frameworks are becoming increasingly common and important. They are the way that object-oriented systems achieve the most reuse. Larger object-oriented applications will end up consisting of layers of frameworks that cooperate with each other. Most of the design and code in the application will come from or be influenced by the frameworks it uses. 9/21/2018 Sima Emadi

How to Select a Design Pattern there are several different approaches to finding the design pattern that's right for your problem: Consider how design patterns solve design problems. Scan Intent sections Study how patterns interrelate. Study patterns of like purpose. Examine a cause of redesign. Consider what should be variable in your design. 9/21/2018 Sima Emadi

How to Select a Design Pattern 9/21/2018 Sima Emadi

How to Use a Design Pattern There is a step-by-step approach to applying a design pattern effectively: 1 . Read the pattern once through for an overview. Pay particular attention to the Applicability and Consequences sections to ensure the pattern is right for your problem. 2. Go back and study the Structure, Participants, and Collaborations sections. Make sure you understand the classes and objects in the pattern and how they relate to one another. 3. Look at the Sample Code section to see a concrete example of the pattern in code. Studying the code helps you learn how to implement the pattern. 9/21/2018 Sima Emadi

How to Use a Design Pattern There is a step-by-step approach to applying a design pattern effectively: 4. Choose names for pattern participants that are meaningful in the application context. The names for participants in design patterns are usually too abstract to appear directly in an application. Nevertheless, it's useful to incorporate the participant name into the name that appears in the application. That helps make the pattern more explicit in the implementation. For example, if you use the Strategy pattern for a text compositing algorithm, then you might have classes SimpleLayout Strategy or TeXLayout Strategy. 9/21/2018 Sima Emadi

How to Use a Design Pattern There is a step-by-step approach to applying a design pattern effectively: 5. Define the classes. Declare their interfaces, establish their inheritance relationships, and define the instance variables that represent data and object references. Identify existing classes in your application that the pattern will affect, and modify them accordingly. 9/21/2018 Sima Emadi

How to Use a Design Pattern There is a step-by-step approach to applying a design pattern effectively: 6. Define application-specific names for operations in the pattern. Here again, the names generally depend on the application. Use the responsibilities and collaborations associated with each operation as a guide. Also, be consistent in your naming conventions. For example, you might use the "Create-" prefix consistently to denote a factory method. 9/21/2018 Sima Emadi

How to Use a Design Pattern There is a step-by-step approach to applying a design pattern effectively: 7- Implement the operations to carry out the responsibilities and collaborations in the pattern. The Implementation section offers hints to guide you in the implementation. The examples in the Sample Code section can help as well. 9/21/2018 Sima Emadi