2/17/2015 sima emadi 1emadilms.ir/wp-content/uploads/2016/05/introduction.pdf · 2/17/2015 sima...

2/17/2015 Sima Emadi 1

فصل اول مقدمه

درافزارهانرمهمهدراستفادهقابلالگوییصورتبهکهاستخبرهنویسانبرنامهتجربیاتواقعدرطراحیالگوهای•.استآمده

کدهایشاندهیسازمانودهینظمدردیگرانگرانبهایتجربیاتازالگوهااینازاستفادهباتوانندمینویسانبرنامه•.کننداستفاده

افزارنرمطراحیدرعموماًکههستمسائلیبرایتکرارقابلحلروشیکطراحی،الگوییکافزارنرممهندسیدر•.کنیممیبرخوردآنبا

.شودفادهاستمختلفشرایطدرتواندمیکهاستمسائلیحلچگونگیبرایشرحیاقالبیکطراحیالگوییک•

گاندهندتوسعهبطوریکهاست،شدهدادهتشخیصارزشمندسازیمستندبرایکهاستحلیراهطراحی،الگوییک•.ببرندکاربهمشابهمسائلحلدرراآنتوانندمیدیگر


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

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

ایهحلراهعنوانبهوکردنداستفادهخاصمسائلحلبرایآنهااززمانیافرادکههستندهاییتکنیکالگوها•.اندشدهشناختهخوب

تنداتمساینازمشابهمسائلبابرخوردهنگامدهندگانتوسعهتااندشدهسازیمستندهاتکنیکاینسپس•.کنندحلراخودمسائلوکننداستفاده

ده،کرنامگذاریگراشیسیستمهایدررامهموتکراریطراحییکاصولیبراساسطراحیالگویهربعبارتی•.کندمیارزیابیودادهتوضیح

.کندمیبیانراداندمیخبرهطراحیککهآنچهازبخشیتنهاطراحیالگوهایاما•

.کندنمیمطرحرابلادرنگیاتوزیعی،همروندینویسیبرنامهبهمربوطالگوهای•

.دهدنمیراشودنوشتهدادهپایگاهیکیاکاربرواسطاینکهبارابطهدرایایدههمچنین•

هر دامنه الگوی خاص خود را نیاز دارد


(الگوهاضرورت استفاده از )فصل اول مقدمهمیبیانمشترکواژگانازاستفادهباراخودمنظورطراحی،مسائلحلهنگامطراحیالگوهایکمکبه•

.کنیم

بناSOLIDقواعداساسبرچونکنندمیهدایتشیءگرادرستطراحیازاستفادهبهراماطراحیالگوهای•.اندشدهنهاده

.هستندپیچیدهمسائلهایحلراهتوصیفبرایکاراروشی•

.نمودنظرتبادلسازی،پیادهجزئیاتبهتوجهبدونتیماعضایسایرباتوانمیراحتیبه•

.هستنداستفادهقابلشیءگرانویسیبرنامهزبانهردروبودهزبانازمستقل•

.دهدمیافزایشطراحدرراگراشیزبانهایازاستفادهمهارتالگوهاایندانستن•


(الگوهاسودمندی )فصل اول مقدمه

کههستند،ایشدهامتحانهایحلراهآنهاکهاستایندرطراحیالگوهایارزش•Bestآنهابهاصطلاحاًونداردوجودشکیآنهاکاراییدر Practiceگویندمی.

باید،اکردهاستفادهآنهاازبارهامطمئناباشیدایباتجربهدهندهتوسعهشمااگر•.باشیدنشنیدهرااسمشانحتیاستممکنآنکه

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

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


(انتظار داشت“ الگوهای طراحی”آنچه که نباید از )فصل اول مقدمه

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

ند،میکنکمکآنهاشدنسادهوپچیدهمشکلاتحلبهچندهرالگوهااین•دادهشافزایراپیچیدگیتوانندمیسادهمشکلاتبرایآنهاازاستفادهاما.باشدآفرینمشکلو

بهلزومیتعمیم،قابلوشفافساده،حلیراهبهیافتندستصورتدر•.نیستالگوهاازحتمیاستفاده


(عوامل ایجاد الگوهای طراحی)فصل اول مقدمه

افزارنرمتوسعهدرگراییشیازاستفاده•

.دارندطراحیدرنمادهاازاستفادهبربسیاریتاکیدگراشیطراحیوتحلیلروشهایاغلب•

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

داردتجربهسالهابهنیازخوبگرایشیطراحی•

افتدمیتفاقاطراحیهنگامدرمجدداستفادهبیشترین•

و ظرافت واحدبندی، انعطاف پذیری، تجریدسبب ارتقای الگوهالذا شده و حاوی اطلاعات ارزشمند طراحی هستند


(SOLIDاصول طراحی )فصل اول مقدمه

The)واحدمسئولیتاصل• Single-Responsibility Principle ) SRP

.دباشداشتهتغییربرایدلیلیکفقطنتیجهدروباشدمسئولیتیکدارایتنهابایدکلاسهر•

Open)بستهبازقاعده• Close Principle OCP)

.بستهتغییربرایولیباشدبازتوسعهبرایباید(غیرهومتدکلاس،)افزارینرمموجودیتیک•

Lisko)لیسکوجایگزینیقاعده• Substantial Principle)

.باشندخودپایهنوعجایگزینبتوانندبایدهانوعزیر•2/17/2015 Sima Emadi 8

(SOLIDاصول طراحی )فصل اول مقدمه

Dependency)وابستگیکردنمعکوسقاعده• Inversion Principle)

وابستهانتزاعاتبهبایددوهرباشند،وابستهپایینسطحماژولهایبهنبایدبالاسطحهایماژول•.باشنداعاتانتزبهوابستهبایدجزئیاتبلکهباشند،جزئیاتبهوابستهنبایدانتزاعات.باشند

Interface)هاواسطتفکیکقاعده• Segregation Principle)

.نمیکنندسازیپیادهراآنهاکهباشندمتدهاییبهوابستهنبایدهاکلاینت•


الگوی طراحی چیست؟

:گویدمیالکساندرکریستوف•مسئله،آنحلراهباهمراهداده،رخبارهاکهاستیمشکلومسئلهبیانگرالگوهر•

کنداستفادهبارهامیلیونجدیدحلراهیافتنبهنیازبدونآنازتوانمیکه

«داردمینگاهدلخواهزمینهدرراتکرارکهعینیشکلیکازتجریدی»الگوتعریفبهترین•آنردکهافتدمیاتفاقخاصیزمینهدرنظرموردمسئلهکهاستاینبیانگرواستحلراهازفراترچیزیالگو•

.دارندوجودنیزدیگریعلاقمندیهای

میربرقراتوازناجبارهایاخاصعلاقمندیهایبینکهاستساختارنوعیحاویالگویکپیشنهادیحلراهواقعدر•.شودارائهنظرموردزمینهدرمسئلهبرایحلراهبهترینتانماید

2/17/2015 Sima Emadi 10


استقراردادهاوتعاملاتساختارها،ها،وابستگیازایمجموعهشاملالگوهر•

مطرحخاصزمینهدرایمسئلهبراینمونهحلیراهوکندمیتعیینصریحراطراحیساختارونامالگوهر•.کندمی

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

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

2/17/2015 Sima Emadi 11


:دهدمیانجامرازیرکارهایخوبالگوییک•

مفاهیمیاراهبردنهدهندمینشانراحلهاراهالگوها:کندمیحلراایمسئله.

هستندمسئلهانجامبرایشدهاثباتحلهایراه:استشدهاثباتمفهومیک

کنندمیتولیدمسئلهیکبرایمستقیمغیرحلیراهالگوهابهترین:نیستمشهودحلراه.

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

2/17/2015 Sima Emadi 12


:داردضروریعنصر4الگویک•

Pattern name

Problem

Solution

Consequence

2/17/2015 Sima Emadi 13

الگوی طراحی چیست؟ نام الگو

کندمیتوصیفراالگوکهاستعبارتی•

.شودمیاستفادهجملهدویایکدرنتایجشوآنحلراهطراحی،مسئلهتوصیفبرایالگوناماز•

:مزایا•تجریدبالاترسطوحدرطراحیانجام•.کندمیترسادهرایکدیگرباموازنهوارتباطنحوهوهاطراحیدربارهکردنفکر•طراحدیکشنریمحتویاتافزایش•کجاهردرآنهامورددرگفتنسخن•

2/17/2015 Sima Emadi 14

الگوی طراحی چیست؟ مسئله

.شودبیانآنحلراهطراحیالگویاینتوسطاستقرارکهمشکلیازشرحی•

شونداستفادهبایدالگوهاکهاستزمانیکنندهتوصیف•

راحیطیکهاینشانهکهاستاشیائییاکلاسساختاریاوطراحیخاصمسائلزمینه،کنندهتوصیف•هستندپذیرانعطاف

.شودتهگرفدرنظربایستیالگوبکارگیریازقبلکهاستشرایطیازلیستیمسئلهیکاوقاتگاهی•

2/17/2015 Sima Emadi 15

الگوی طراحی چیست؟ راه حل

استآنهامیانارتباطونیازموردطراحیاجزا•

استهمکاریهایشانومسئولیتهاروابط،طراحی،یسازندهعناصرکنندهتوصیف•

.شودمیاستفادهبسیاریوضعیتهایدرکهاستقالبی•

استمشکلحلبرایعناصرازخاصیترتیبنمودنمشخصوطراحیمسئلهازانتزاعیتوصیفیک•

2/17/2015 Sima Emadi 16

الگوی طراحی چیست؟ نتایج

.دهدمینشانفضاوزماننظرازراالگوهابکارگیریموازنهونتیجه•

هستندضروریالگوهابکارگیریفوائدوهاهزینهدرکوپیشنهاداتارزیابیبرای•

گرفتدرنظررازمانوفضابینموازنهبایستینتایجبیاندر•

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

کندمیکمکصریحبطورآنهاارزیابیوالگودرکبهنتایجاین•

2/17/2015 Sima Emadi 17

الگوی طراحی چیست؟ زمینه

کرداستفادهطراحیالگویاینازبایستیوقتچه•

2/17/2015 Sima Emadi 18

smalltalkالگوهای طراحی در MVC

.شودمیاستفادهالگوهادرکاربرواسطساختمنظوربه•

داردmodel/view/controllerنامهایبهشینوعسه•

•Modelکاربردشییک(application object)است.

•Viewکندمیمنعکسشفافبصورترامدلوضعیتواستنمایشگردرشینمایشنحوه

•Controllerدکنمیتعریفرادهدمینشانالعملعکسکاربرورودیمقابلدرکاربرواسطکهراروشی.

2/17/2015 Sima Emadi 19

smalltalkالگوهای طراحی در MVC.کندمیتجزیهراآنهاviewوmodelبینsubscribe/notifyپروتکلایجادباMVCالگوی•

سازدمطلعرامربوطههایviewبایستیmodelمدل،هایدادهتغییربا•

•Viewنمایدمیکسبرافرصتیخودشرسانیبروزبراینیز.

روشاینمزیت•.استمختلفنمایشهایمنظوربهمدلیکبرایviewچندینداشتن•آنهامجددنوشتنبدونمدلیکبرایجدیدهایviewایجاد•

2/17/2015 Sima Emadi 20


2/17/2015 Sima Emadi 21


باmodelدادهمقادیرتغییرباviewکندمیبرقرارارتباط.Viewبهدسترسیبراینیزبرقرارارتباطmodelبامقادیر

کندمی

A=10%

B=40%

C=30%

D=20%

Application data

A

B

C

D

A DCB

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

Model2/17/2015 Sima Emadi 22


ار می دهد بدون ای تجزیه می کند که تغییر در یکی بقیه اشیا را تحت تاثیر قربگونهاین روش اشیا را •.اینکه شی تغییر یافته نیازی به دانستن جزئیات اشیا دیگر داشته باشد

ک از دکمه های متفاوت یا یپنلیمثل یک کنترل . تو باشندتودرها می توانند viewدر این الگو •object inspector در یکdebugger.

•MVC با استفاده از کلاسهایcomposite view ازviewهای تودرتو پشتیبانی می کند.

.کاربر تغییر می دهدورودیهایرا به viewاین است که اجازه تغییر نحوه پاسخ MVCکاربرد دیگر •

•MVCمکانیزمهای پاسخ را در یک شی کنترلی بسته بندی می کند

2/17/2015 Sima Emadi 23


•Viewیکازخاصپاسخاستراتژیسازیپیادهمنظوربهinstanceکندمیاستفادهکنترلرزیرکلاساز.

.استstrategyالگویازاینمونهview-controllerبینرابطه•

•Strategyدهدمینشانراالگوریتمیککهاستشیئی.

•MVCمثلدیگریطراحیالگوهایازfactory methodفرضپیشکنترلیکلاسنمودنمشخصجهت.کندمیاستفادهviewیکبهscrollingنمودناضافهجهتdecoratorالگویازیاviewبرای

شوندمیایجادstrategyوobserver،compositeالگوهایتوسطMVCدراصلیروابطاما•

2/17/2015 Sima Emadi 26

2/17/2015 Sima Emadi 27

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

وهاالگقالب مستند سازی برای الگوهای طراحی یا توصیف كندميمشخصراالگوماهیتزیراالگوبرایمفیدوخوبنامیک الگونام

دهدمیانجامالگوکهكاريدربارهمختصروکوتاهجملهیک(مفیدومختصرصورتبهحلراهومسئلهتعریف)

(intent)نیتوقصدهدف

شودمیشناختهآنباالگوکهدیگرینامهای مستعارنام

OMTبرمبتنينمادهايازاستفادهباالگوازگرافیکینمایشیک (structure)ساختار

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

دهندهتشکیلاجزا

(participant)شركایا

راوظایفشانتاکنندمیهمکاریهمبادهندهتشکیلاجزایچگونهدهندانجام

(collaboration)همکاریها

trade)موازنه.موردنظرالگویازاستفادهنتایج off)ازحاصل

چیست؟الگوایناستفاده

(consequences)نتایج

نظرموردالگویسازیپیادهبرایتکنیکهایی سازیپیاده2/17/2015 Sima Emadi 28

ئلهمسحلچگونگی.دهدمیتوضیحراطراحیمسائلکهسناریوییدهدمینشانالگودراشیاوکلاسهاساختارتوسطرا

(motivation)انگیزه

ازاییهنمونهچه؟چیسترودبکارتواندمیالگواینکهوضعیتهاییدهدمینشانراآنالگوکهداردوجودضعیفهایطراحی

(applicability)کاربردپذیری

مینشان++Cدرراالگوسازیپیادهچگونگیکهکدازبخشهاییدهد

نمونهکد

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

شدهشناختهاستفاده

یابانزهماندرراالگوهادیگروالگواینبینایستایوپویاارتباطات.میدهدنشانسیستم

مرتبطالگوهای

2/17/2015 Sima Emadi 29

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 clientsexpect. Adapter lets classes work together that couldn't otherwisebecause of incompatible interfaces.

• Bridge Decouple an abstraction from its implementation so that the two can vary independently.

2/17/2015 Sima Emadi 30

The Catalog of Design Patterns• Builder Separate the construction of a complex object from its

representation so that the same construction process can createdifferent representations.

• Chain of Responsibility Avoid coupling the sender of a request to itsreceiver by giving more than one object a chance to handle therequest. Chain the receiving objects and pass the request along thechain 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.

2/17/2015 Sima Emadi 31


• Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.

• Decorator Attach additional responsibilities to an object dynamically.Decorators provide a flexible alternative to subclassing for extendingfunctionality.

• Facade Provide a unified interface to a set of interfaces in a subsystem.Façade defines a higher-level interface that makes the subsystemeasier to use.

2/17/2015 Sima Emadi 32


• Factory Method Define an interface for creating an object, but letsubclasses decide which class to instantiate. Factory Method lets aclass defer instantiation to subclasses.

• Flyweight Use sharing to support large numbers of fine-grainedobjects efficiently.

• Interpreter Given a language, define a representation for its grammaralong with an interpreter that uses the representation to interpretsentences in the language.

2/17/2015 Sima Emadi 33


• Iterator Provide a way to access the elements of an aggregate objectsequentially without exposing its underlying representation.

• Mediator Define an object that encapsulates how a set of objectsinteract. Mediator promotes loose coupling by keeping objects fromreferring to each other explicitly, and it lets you vary their interactionindependently.

• Memento Without violating encapsulation, capture and externalize anobject's internal state so that the object can be restored to this statelater.

2/17/2015 Sima Emadi 34


• Observer Define a one-to-many dependency between objects so thatwhen one object changes state, all its dependents are notified andupdated automatically.

• Prototype Specify the kinds of objects to create using a prototypicalinstance, and create new objects by copying this prototype.

• Proxy Provide a surrogate or placeholder for another object to controlaccess to it.

2/17/2015 Sima Emadi 35


• Singleton Ensure a class only has one instance, and provide a globalpoint of access to it.

• State Allow an object to alter its behavior when its internal statechanges. The object will appear to change its class.

• Strategy Define a family of algorithms, encapsulate each one, andmake them interchangeable. Strategy lets the algorithm varyindependently from clients that use it.

2/17/2015 Sima Emadi 36


• Template Method Define the skeleton of an algorithm in an operation,deferring some steps to subclasses. Template Method lets subclassesredefine certain steps of an algorithm without changing the algorithm's structure.

• Visitor Represent an operation to be performed on the elements of anobject structure. Visitor lets you define a new operation withoutchanging the classes of the elements on which it operates.

2/17/2015 Sima Emadi 37


2/17/2015 Sima Emadi 38

Organizing the catalog

Design patterns vary in their granularity and level of abstraction.

• We classify design patterns by two criteria

• Purpose

• scope

2/17/2015 Sima Emadi 39


2/17/2015 Sima Emadi 40

Scope: domain over which a pattern

applies

Purpose: reflects what a pattern does


• 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 objectsinteract and distribute responsibility.

2/17/2015 Sima Emadi 41


• 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 patternslabeled "class patterns" are those that focus on class relationships.

2/17/2015 Sima Emadi 42

Note that most patterns are in the Object scope.

Six types of design patterns

1. Creational class patterns defer some part of object creation to subclasses

2. Creational object patterns defer some part of object creation to another object

3. Structural class patterns use inheritance to compose classes

4. Structural object patterns describe ways to assemble objects

5. 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

2/17/2015 Sima Emadi 43

Organizing the catalogThere are other ways to organize the patterns.

• Some patterns are often used together. For example, Composite is often used withIterator Visitor.

• Some patterns are alternatives: Prototype is often an alternative to AbstractFactory.

• Some patterns result in similar designs even though the patterns have differentintents. For example, the structure diagrams of Composite and Decorator aresimilar.

Patterns which reference one another Additional ways to organize design patterns

2/17/2015 Sima Emadi 44

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

Yet another way to organize design patterns is

according to how they reference each other in their

"Related Patterns" sections.

2/17/2015 Sima Emadi 45

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

2/17/2015 Sima Emadi 46

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.

Sima Emadi 472/17/2015

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


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.


Review cont..

Class inheritance versus Interface inheritance

• Difference between an object’s class and it’s type : type only refers to it’sinterface, 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 notdistinguish the difference.

• Java, recognizes the difference.


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 toother classes and not to be instantiated.


Review cont..

Aggregation and Association

• Aggregation means on object owns another object (having orbeing part of)

• It implies that an aggregate object and its owner have identicallifetimes.

• Association (acquaintance, using ) means that object knowsanother object. They use each others operations but they are notresponsible for each other. They have different lifetimes


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

2/17/2015 Sima Emadi 53

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

2/17/2015 Sima Emadi 54

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.

•



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.



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.



Determining Granularity

• Flyweight pattern describes how to support huge numbers of objects atthe finest granularities.

• Other design patterns describe specific ways of decomposing anobject into smaller objects.

• Abstract Factory and Builder yield objects whose only responsibilitiesare creating other objects.

• Visitor and Command yield objects whose only responsibilities are toimplement a request on another object or group of objects.



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.



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 o f objects that visitors can visit.



Specifying Object Implementations

• An object's implementation is defined by its class.

• The class specifies the object's internal data and representation and defines theoperations the object can perform.



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.




• New classes can be defined in terms of existing classes using class inheritance.




• An abstract class is one whose main purpose is to define a common interface forits subclasses.

• An abstract class will defer some or all of its implementation to operations definedin subclasses;

• hence an abstract class cannot be instantiated.

• The operations that an abstract class declares but doesn't implement are calledabstract operations.

• Classes that aren't abstract are called concrete classes.




• 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 parentclasses.

• Class inheritance lets you define classes simply by extending other classes,making it easy to define families of objects having related functionality.




• Abstract class




• A mixin class is a class that 's intended to provide an optional interface orfunctionality to other classes.

• It's similar to an abstract class in that it's not intended to be instantiated.

• Mixin classes require multiple inheritance:



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 theobject'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 canrespond.

• An object can have many types, and objects of different classes can have the sametype.




• there's a close relationship between class and type.

• Because a class defines the operations an object can perform, it also defines theobject's type.

• When we say that an object is an instance of a class, we imply that the objectsupports the interface defined by the class.




• difference between class inheritance and interface inheritance (or subtyping).

• Class inheritance defines an object's implementation in terms of another object'simplementation.

• In short, it's a mechanism for code and representation sharing.

• interface inheritance (or subtyping) describes when an object can be used inplace of another.




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 itsoperations.

• In contrast, an object's type only refers to its interface—the set of requests towhich it can respond.

• An object can have many types, and objects of different classes can have thesame type.




• 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, butComposite often defines a common implementation.

• Command, Observer, State, and Strategy are often implemented with abstractclasses that are pure interfaces.



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.Sima Emadi 732/17/2015


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).

•



• Programming to an interface, not an implementation

• all classes derived from an abstract class simply override interfaces andtherefore they can all respond to the requests to the abstract class (i.e. theyare all subtypes)

• This implies that a subclass merely adds or overrides operations and doesnot hide operations of the parent class.

• All subclasses can then respond to the requests in the interface of thisabstract class, making them all subtypes of the abstract class.




• 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)




• 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.




• 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.




• 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.




• 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).Sima Emadi 802/17/2015



• This style of reuse is called black-box reuse, because no internal details ofobjects are visible.

Objects appear only as "black boxes."




• Advantages and disadvantages of both:

-Ad: Class inheritance is defined statically at compile time, easy to use sinceit has the language support. Easy to modify implementation by overridingsome operations:

- Dis: Can not change inherited implementation at runtime (its defined atcompile time).

worse: Inheritance breaks encapsulation. Any change to parentimplementation will force subclasses to change. Implementation dependencymakes reuse of subclasses very limited, as any change to subclasses need tochange parents.





-Object Composition is defined dynamically at runtime trough acquiringreferences to other objects

- We do not break encapsulation because objects are accessed solely throughinterfaces (but that means some effort on good interface design)

- Any object can be replaces with another at runtime as long as it has sametype.

- Implementation written in terms of interfaces so much less implementationdependency





-That leads us to our second principle of object-oriented design:

Favor object composition over class inheritance.





• 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.





• 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.




• advantages and disadvantages of composition

• defined dynamically at run-time through objects acquiring references to otherobjects.

• requires carefully designed interfaces.

• Moreover, because an object's implementation will be written in terms of objectinterface s, there are substantially fewer implementation dependencies.

• Favoring object composition over class inheritance helps you keep each classencapsulated 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), andthe system's behavior will depend on their interrelationships instead of beingdefined in one class.



• Delegation:

• A way to making composition powerful for reuse.

• - Two objects are involved in handling a request:

• one object receives the request, and delegates the request to be handled by itsdelegate. (the receiver passes a reference to itself to the delegate)

• This is analogous to subclasses deferring requests to parent classes.



• Delegation:

• But with inheritance, an inherited operation can always refer to the receivingobject through the this member variable in C++ and self in Smalltalk .

• To achieve the same effect with delegation, the receiver passes itself to thedelegate to let the delegated operation refer to the receiver.



• Delegation:

• - Example : Window and Rectangle objects (instead of using inheritance,instead of window being a rectangle, it can have a rectangle



• Delegation:



• 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.

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).



• 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) (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 .




• To parameterize a sorting routine by the operation it uses to compare elements,we could make the comparison

1. 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 thefunction to call to compare the elements.




• Important differences: Object composition let you change the behavior at run time. Neither inheritance nor parameterized types can change at runtime.

• Inheritance provide default implementation for operations, templates let you change the type a class uses.



• 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.




• Design patterns help to impose the behavior at run-time. Composite andDecorator patterns are especially useful for building complex run-timestructures.

• In general run-time structures aren’t clear from code unless you understandthe pattern.




• Consider the distinction between object aggregation and acquaintance andhow 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 identicallifetimes.




• 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'tresponsible for each other.

• Acquaintance is a weaker relationship than aggregation and suggests muchlooser coupling between objects.




• In our diagrams, a plain arrowhead line denotes acquaintance.

• An arrowhead line with a diamond at its base denotes aggregation:

Sima Emadi 1002/17/2015


• Designing for Change:

• A design that does not take change into account risks a major redesign in thefuture.

• Each design pattern lets some aspect of system structure vary independentlyof the other aspects, making system more robust to a particular type ofchange.

Sima Emadi 1012/17/2015



• Common causes of change that are addressed by design pattern :

1- Creating an object by specifying a class explicitly (committing to animplementation not to an interface)

- solution create an object indirectly; subject of Abstract Factory, Factory Method,Prototype patterns

Sima Emadi 1022/17/2015



2- Dependence on specific operations. (committing to one way of respondingto a request)

- solution: avoid hard-coded request; Chain of responsibility, Command patterns

Sima Emadi 1032/17/2015



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

Sima Emadi 1042/17/2015



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, VisitorSima Emadi 1052/17/2015


• 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 haveto.

• Design patterns that reduce dependencies can increase internal reuse.

• Looser coupling boosts the likelihood that one class of object can cooperate withseveral others.

Sima Emadi 1062/17/2015



• For example, when you eliminate dependencies on specific operations byisolating and encapsulating each operation, you make it easier to reuse anoperation in different contexts.

• The same thing can happen when you remove algorithmic andrepresentational dependencies too.

Sima Emadi 1072/17/2015



• Design patterns also make an application more maintainable when they' re used tolimit platform dependencies and to layer a system.

• They enhance extensibility by showing you how to extend class hierarchies and howto exploit object composition.

• Reduced coupling also enhances extensibility.

• Extending a class in isolation is easier if the class doesn't depend on lots of otherclasses.

Sima Emadi 1082/17/2015


• Toolkits:

• Often an application will incorporate classes from one or more libraries ofpredefined 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, associativetables, stacks, and the like.

Sima Emadi 1092/17/2015


• 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.

Sima Emadi 1102/17/2015


• Toolkits:

• Toolkit design is arguably harder than application design, because toolkitshave to work in many applications to be useful.

• Moreover, the toolkit writer isn't in a position to know what those applicationswill be or their special needs.

• That makes it all the more important to avoid assumptions and dependenciesthat can limit the toolkit's flexibility and consequently its applicability andeffectiveness.

Sima Emadi 1112/17/2015


• Framework and patterns:

• Framework is a set of cooperating classes that make of reusable design for aspecific class of software. It usually contains concrete classes that can be usedas is. It’s a pre-determined architecture for a particular application

• Patterns and Frameworks are different:

1- Design patterns are more abstract than framework

2- Design patterns are smaller architectural elements, a typical framework usesseveral patterns

3- Design patterns are less specialized

Sima Emadi 1122/17/2015


• there are several different approaches to finding the design pattern that's rightfor 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.

Sima Emadi 1132/17/2015

How to Select a Design Pattern

• There is a step-by-step approach to applying a design pattern effectively:

1 . Read t he pattern once through for an overview. Pay particular attention tothe Applicability and Consequences sections to ensure the pattern is right foryour 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 theyrelate to one another.

3. Look at the Sample Code section to see a concrete example of the pattern incode. Studying the code helps you learn how to implement the pattern.

Sima Emadi 1142/17/2015

How to Use a Design Pattern


• 4. Choose names for pattern participants that are meaningful in theapplication context.

• The names for participants in design patterns are usually too abstract to appeardirectly in an application.

• Nevertheless, it's useful to incorporate the participant name into the name thatappears 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.

Sima Emadi 1152/17/2015



5. Define the classes. Declare their interfaces, establish their inheritancerelationships, and define the instance variables that represent data and objectreferences.

• Identify existing classes in your application that the pattern will affect, andmodify them accordingly.

Sima Emadi 1162/17/2015



• 6. Define application-specific names for operations in the pattern. Here again, thenames generally depend on the application.

• Use the responsibilities and collaborations associated with each operation as aguide.

• Also, be consistent in your naming conventions.

• For example, you might use the "Create-" prefix consistently to denote a factorymethod.

Sima Emadi 1172/17/2015



7- the operations to carry out the responsibilities and collaborations in thepattern.

• The Implementation section offers hints to guide you in the implementation.

• The examples in the Sample Code section can help as well.

Sima Emadi 1182/17/2015


2/17/2015 sima emadi 1emadilms.ir/wp-content/uploads/2016/05/introduction.pdf · 2/17/2015 sima...

Documents