Sunteți pe pagina 1din 3

ablonul Observer Abstract Factory

-Definii o dependen unul-la-mai-muli ntre obiecte astfel nct atunci cnd un -Ofer o interfa pentru crearea de familii de obiecte nrudite sau dependente fr
obiect i schimb starea, toate dependenele sale sunt anunate i actualizate automat specificarea claselor lor concrete
-Pot exista muli observatori Aplicabilitate
-Fiecare observator poate reaciona diferit la aceeai notificare -Sistemul trebuie s fie independent de cum sunt create, compuse i reprezentate
-Sursa de date (subiectul) trebuie s fie ct mai decuplat posibil de observator(i) produsele sale
-Sistemul trebuie configurat de una din mai multe familii de produse
-Trebuie forat ca o familie de obiecte produs s fie folosite mpreun

-Cuplaj minimal i abstract ntre subiect i observatori -Izolarea claselor concrete


-Suport pentru comunicare de tip difuzare (broadcast) apar n ConcreteFactories nu n codul clientului
--Modificri neateptate -Faciliteaz schimbul de familii de produse
ntruct observerii nu tiu unul de existena celuilalt, pot apare modificri incorecte, un ConcreteFactory apare ntr-un singur loc
n cascad uor de modificat
-Promoveaz consistena ntre produse
Metoda Factory toate produsele unei familii se modific mpreun, n acelai timp
-Definete o interfa pentru crearea unui obiect, dar las subclasele s decid ce -Este dificil susinerea de tipuri noi de produse
clas s instanieze.
-Metoda Factory permite unei clase s defere instanierea subclaselor Singleton
Cunoscut i ca Constructor Virtual -Asigur ca o clas s aib doar o singur instan i furnizeaz un punct de acces
Aplicabilitate global la ea
-O clas nu poate anticipa clasa obiectelor pe care trebuie s le creeze Aplicabilitate
-O clas dorete ca subclasele sale s specifice obiectele pe care le creeaz -dorim exact o instan a unei clase
-Clasele deleg responsibilitatea uneia sau mai multor subclase ajuttoare -accesibilitate pentru clieni dintr-un singur punct
-dorim ca instana s fie extensibil
-poate permite deasemenea i un set numrabil de instane
-optimizare fa de vizibilitatea global
-mai bine dect o clas static:
nu se poate rzgndi

Elimin legarea ntre clasele specifice aplicaiei din cod


-codul de creare folosete doar interfaa clasei Product
Faciliteaz derivarea
-subclasele pot astfel modifica produsul creat
Poate conecta ierarhii paralele de clase
-las clienii s apeleze FM
--Clienii ar trebui s deriveze din Creator doar pentru a crea un anumit obiect -Acces controlat la instana unic
ConcreteProduct. -Permite rafinarea operaiilor i reprezentrii
-Permite un numr variabil (dar precis) de instane
ablonul Prototype -Reducerea vizibilitii globale
-Specificai tipul obiectelor care se creeaz folosind o instan prototipic
-Creai obiecte noi copiind acest prototip ablonul Command
Aplicabilitate ncapsuleaz cereri ca obiecte, i permite:
cnd un sistem trebuie s fie independent de cum sunt create, compuse i -parametrizarea clienilor cu diferite cereri
reprezentate produsele sale -nlnuirea sau log-area cererilor
-cnd clasele de instaniat sunt specificate la execuie -suport pentru operaii anulabile (UNDO)
-evitai construirea unei ierarhii de clase-factory paralel cu ierarhia claselor de Aplicabilitate
produse -Parametrizarea obiectelor
-Specificarea, nlnuirea, i executarea cererilor la diferite momente
-Suport undo
-Modelarea tranzaciilor

Conseciinte:
-Adugarea i tergerea produselor la execuie
-Mai puin derivare
evit ierarhia paralel pentru creatori -Decupleaz Invoker de Receiver
-Specificarea de obiecte noi prin varierea valorilor prototipurilor
clientul se comport diferit prin delegarea ctre prototip -Comenzile sunt obiecte ale unor clase
-Specificarea de obiecte noi prin varierea structurii prototipurilor -Comenzi compuse
produse compuse -Uor de adugat comenzi noi
--Fiecare subclas a Prototype trebuie s implementeze clone -Invoker nu se modific
dificil cnd clasele exist deja sau obiectele interne nu permit copierea sau au -cod stabil- Principiul Deschis-nchis
referine circulare --Potenial pentru un exces de clase de tip command
ablonul Composite ablonul Mediator
-Trateaz obiectele individuale i compunerile acestor obiecte uniform Definete un obiect ce ncapsuleaz cum interacioneaz o mulime de obiecte
-Compune obiectele n structuri arborescente pentru a reprezenta agregri recursive Promoveaz cuplajul redus prin faptul c obiectele nu mai fac referin direct unele la
Aplicabilitate altele, permind varierea independent a interaciunii lor
-reprezentarea ierarhiilor de obiecte de tip parte-ntreg Aplicabilitate:
-abilitatea de a ignora diferena dintre compuneri de obiecte i obiecte individuale -O mulime de obiecte comunic ntr-un mod bine definit dar complex;
-Refolosirea unui obiect este dificil deoarece comunic cu prea multe alte obiecte
-Un comportament distribuit ntre mai multe clase ar trebui s fie readaptabil fr
derivare
Conseciinte
-Limiteaz derivarea
-Decupleaz colegii
-Simplific protocoalele obiectelor
-nlocuiete interaciunile mai-muli-la-mai-muli cu interaciuni unul-la-mai-muli
(mai uor de neles, extins, meninut)
-Definete ierarhii uniforme de clase -Abstractizeaz cooperarea obiectelor
-Face clienii simpli --Centralizeaz controlul
-Mai uor de extins Mediatorul se poate transforma ntr-un monolit dificil de ntreinut
--Design prea general
ablonul Strategy
Chain of Responsibility Definete o familie de algoritmi, ncapsuleaz fiecare algoritm, i face
-Decupleaz transmitorul cererii de primitor interschimbabili
oferind mai multor obiecte ansa de a trata cererea Permite algoritmului s varieze independent de clienii ce l folosesc
-Pune primitorii ntr-un lan i transmite cererea de-a lungul lanului Aplicabilitate
pn ce un obiect o trateaz -Sunt necesare variante diferite ale unui algoritm
Aplicabilitate -Un algoritm folosete date despre care clienii nu trebuie s tie evit expunerea
-mai mult dect un obiect poate trata o cerere structurilor de date complexe, specifice algoritmului
-mulimea de obiecte ce pot trata cererea trebuie s fie specificabil dinamic Multe clase relaionate difer doar prin comportament configureaz o clas cu un
-trimitem o cerere la mai multe obiecte fr s specificm primitorul comportament particular

-Familii de algoritmi nrudii


-Alternativ la derivare
-Elimin instruciunile condiionale
-Cuplaj redus
--Exces de comunicare ntre Strategy i Context
clientul (trimitorul) nu trebuie s tie cine i va trata cererea
--Clientii trebuie s fie contieni de diferitele strategii
trimitorul i primitorul nu se cunosc unul pe cellalt
--Numr sporit de obiecte
-Flexibilitate n asignarea responsabilitilor ctre obiecte
responsabilitile se pot aduga sau schimba
ablonul State
lanul se poate modifica la execuie
permite unui obiect s i modifice comportamentul cnd i se modific starea intern
--Cererile pot rmne netratate dac lanul nu a fost configurat corect
obiectul va prea c i schimb clasa
Aplicabilitate
ablonul Decorator
-comportamentul obiectului depinde de starea sa
Adaug responsabiliti unui obiect particular, mai degrab dect clasei sale
-trebuie s i modifice comportamentul la execuie n funcie de stare
Ataeaz dinamic responsabiliti adiionale unui obiect.
-operaii cu instruciuni condiionale multiple, depinznd de starea obiectului
O alternativ flexibil la derivare
Cunoscut i ca Wrapper
Aplicabilitate
-Adaug responsabiliti obiectelor transparent i dinamic fr s afecteze alte
obiecte
Extinderea prin derivare nu e practic poate duce la prea multe subclase

-Localizeaz comportamentul specific strilor i partiioneaz comportamentul pentru


stri diferite
-Face explicit tranziia ntre stri

-Mai flexibil dect motenirea static


permite amestecarea i potrivirea responsabilitilor
permite aplicarea unei proprieti de dou ori

-Evit clasele ncrcate de prea multe cracteristici specifice n partea de sus a


ierarhiei
--O mulime de obiecte mici uor de adaptat, dar dificil de nvat i depanat
--Un decorator i componenta sa nu sunt identice
Principiul deschis-nchis (PDI) Principiul Echivalenei Refolosire/Folosire (PER)
Entitile software trebuie s fie deschise la extinderi, dar nchise la modificri. Un element software reutilizabil nu poate fi refolosit cu adevrat n practic dac nu
Deschidere la extinderi este gestionat de un sistem de distribuie de un anumit tip
Comportamentul modulului poate fi extins Nu exist clas reutilizabil
nchidere la modificri -fr garania notificrii, siguranei i asistenei
Codul surs al modulului nu trebuie modificat -trebuie integrat ntregul modul (nu se poate reutiliza mai puin)
Modulele trebuie scrise astfel nct s poat s fie extinse fr s fie modificate.
Nici un program semnificativ nu poate fi 100% nchis. Principiul reutilizrii comune (PRC)
nchidere strategic, nu complet Toate clasele unui package [library] trebuie refolosite mpreun. Dac refolosim o
nchiderea se obine prin utilizarea abstractizrii clas din pachet, le refolosim pe toate.
Pachetele de componente reutilizabile trebuie grupate dup utilizarea ateptat, Nu
Principiul Substituiei (Liskov)- PSL dup:funcionalitate comun, nici alt clasificare arbitrar.
Prin motenire, orice proprietate adevrat despre obiectele supertipului trebuie s Clasele sunt de obicei refolosite n grupuri pe baza colaborrii ntre librrii de clase.
rmn adevrat despre obiectele subtipului. Cnd depind de un pachet, depind de fiecare clas din acel pachet!
Funciile ce folosesc pointeri/ referine la clasele de baz trebuie s poat folosi
obiecte ale claselor derivate fr s tie aceasta. Principiul nchiderii Comune (PC)
Orice cod ce poate chema legal metodele altei clase Clasele unui pachet trebuie s fie nchise fa de aceleai tipuri de modificri.
-Trebuie s poat substitui orice subclas a clasei respective, fr modificri O modificare ce afecteaz pachetul, afecteaz toate clasele acelui pachet.
Clasele care se modific mpreun trebuie grupate la un loc
Principiul Inversrii Dependenelor (PID) Scop: limitarea dispersrii modificrilor ntre pachetele distribuite
-Modulele de nivel-nalt nu trebuie s depind de modulele de nivel sczut. Ambele Clasele unui pachet trebuie s fie coezive
trebuie s depind de abstraciuni. Pentru un anumit tip de modificare, fie se modific toate clasele unei componente, fie
-Abstraciunile nu trebuie s depind de detalii. Detaliile trebuie s depind de nu se modific nici una
abstraciuni.
O clas de baz ntr-o ierarhie nu trebuie s i tie subclasele Principiul dependenelor aciclice
Modulele cu implementri detaliate depind de abstraciuni, i nimic nu depinde de ele Structura de dependene a componentei distribuite trebuie s fie un Graf Direcionat
Aciclic.
Principiul Segregrii Interfeelor (PSI) Nu trebuie s existe cicluri.
Clienii nu trebuie forai s depind de interfee pe care nu le folosesc.
Mai multe interfee specializate pe fiecare client sunt mai bune dect o interfa de Principiul Dependenelor Stabile
interes general Dependenele ntre componente trebuie s fie n direcia stabilitii.
Consecin: O component trebuie s depind de componente mai stabile dect ea.
-impactul modificrilor unei interfee este mai mic dac interfaa este mai mic
-poluarea interfeelor Principiul Abstraciunilor Stabile (PAS)
Abstractizarea unui pachet trebuie s fie proporional cu stabilitatea sa!
Pachetele maximal stabile trebuie s fie maximal abstracte.
Pachetele instabile trebuie s fie concrete.
Arhitectura Ideal
-Pachete instabile (modificabile) n partea superioar trebuie s fie concrete
-Pachetele stabile (greu de modificat) n partea inferioar