1.

Principiul deschis-închis (PDI) necesitatea unui mecanism de impunere a ordinii la

Deschidere la extinderi nivel mai înalt
Comportamentul modulului poate fi extins clustere (Meyer); categorii de clase (Booch);
Închidere la modificări arii de subiect (Coad)
Codul sursă al modulului nu trebuie modificat Pachete
Modulele trebuie scrise astfel încât să poată să fie extinse fără să o grupare logică de declaraţii ce pot fi importate în alte programe
fie modificate. (în Java şi Ada)
Modificările datelor publice aduc un risc de “deschidere” a containere pentru un grup de clase (UML)
modulului raţionament la un nivel de abstractizare mai înalt
Pot provoca un efect de modificări în cascadă, în mai Probleme ale design-ului de nivel înalt
multe locaţii neaşteptate; Scop
Erorile pot fi dificil de corectat/ de găsit în totalitate partiţionarea claselor unei aplicaţii conform unor criterii
Corecturile pot introduce erori în alte părţi şi apoi alocarea acelor partiţii unor pachete (packages)
Membrii non-privaţi sunt modificabili Probleme
Pot schimba starea clasei Care sunt criteriile optime de partiţionare?
ITE este neelegantă şi periculoasă Ce principii controlează design-ul pachetelor?
Dacă un modul încearcă să convertească dinamic un creare şi dependenţe între pachete
pointer la clasa de bază către una dintre clasele derivate, de câte Proiectăm mai întâi pachetele? Sau mai întâi clasele?
ori se extinde ierarhia de clase, se va modifica şi modulul i.e. abordarea top-down vs. bottom-up
Sunt uşor de recunoscut prin structurile tip switch sau if- Abordare
else Definirea principiilor ce guvernează proiectarea
Nu toate aceste situaţii încalcă PDI pachetelor
Doar când sunt folosite ca filtre creare şi inter-relaţii şi utilizare pachete
2. Principiul Substituţiei (Liskov)- PSL Principii ale design-ului OO de nivel înalt
Cheia PID: abstractizarea şi polimorfismul Principii de Coeziune
Implementate prin moştenire Principiul Echivalenţei Refolosire/Folosire (REP)
Cum se măsoară calitatea moştenirii? Principiul Reutilizării Comune (PRC)
Prin moştenire, orice proprietate adevărată despre obiectele Principiul Închiderii Comune (PÎC)
supertipului trebuie să rămână adevărată despre obiectele Principii de Cuplaj
subtipului. B.Liskov, 1987 Principiul Dependenţelor Aciclice (PDA)
Funcţiile ce folosesc pointeri/ referinţe la clasele de bază trebuie să Principiul Dependenţelor Stabile (PDS)
poată folosi obiecte ale claselor derivate fără să ştie aceasta. Principiul Abstracţiunilor Stabile (PAS)
R.Martin, 1996 Ce înseamnă reutilizabilitatea?
PSL: despre Semantică şi Înlocuire Copy-paste înseamnă reutilizabilitate?
Înţelegeţi înainte de a proiecta Dezavantaj: Tu eşti proprietarul copiei!
Semantica şi scopul fiecărei metode şi clase trebuie Trebuie să o schimbi, să o depanezi
clar documentat eventual codul diverge
Lipsa înţelegerii utilizatorului va duce la încălcări de Mentenanţa este un coşmar
facto ale PSL Definiţia lui Martin:
Substitutabilitatea este crucială Reutilizez cod dacă şi numai dacă nu am nevoie
Oriunde se face referire la o clasă în cod, orice niciodată să văd codul sursă
subclase existente sau viitoare ale sale trebuie să fie 100% trataţi codul refolosit ca pe un produs  nu trebuie să
substituibile facem noi mentenanţa
Pentru că, mai devreme sau mai târziu, cineva va Clienţii (cei care refolosesc) pot decide la momentul oportun să
înlocui clasa respectivă folosească o versiune mai nouă a unei componente
3. Principiul Inversării Dependenţelor (PID) 5. Principiul Echivalenţei Refolosire/Folosire (PER)
Modulele de nivel-înalt nu trebuie să depindă de modulele de nivel Granularitatea de refolosire e granularitatea de distribuţie (release).
scăzut. Ambele trebuie să depindă de abstracţiuni. Doar componentele ce pot fi uşor urmărite (în cod, în versiunile
Abstracţiunile nu trebuie să depindă de detalii. Detaliile trebuie să ulterioare), pot fi refolosite eficient. R. Martin, 1996
depindă de abstracţiuni. Adică?
O clasă de bază într-o ierarhie nu trebuie să îşi ştie subclasele Un element software reutilizabil nu poate fi refolosit cu
Modulele cu implementări detaliate depind de abstracţiuni, şi nimic adevărat în practică dacă nu este gestionat de un sistem de
nu depinde de ele distribuţie (release system) de un anumit tip
PDI= Scopul, PID= mecanismul ex. Numere sau nume asociate elementului
PSL= asigurarea pentru PID refolosit
Proiectaţi centrat pe interfeţe: Nu există ”clasă reutilizabilă”
Interfeţele/ clasele abstracte: fără garanţia notificării, siguranţei şi
Tind să se schimbe mai rar asistenţei
Abstracţiunile sunt puncte de articulare în care este mai trebuie integrat întregul modul (nu se poate
uşor de extins/ modificat reutiliza mai puţin)
Nu ar trebui să fie necesară modificarea abstracţiunilor 6. Principiul reutilizării comune (PRC)
(PDI) Toate clasele unui package [library] trebuie refolosite împreună.
Excepţii: Dacă refolosim o clasă din pachet, le refolosim pe toate.
Unele clase este foarte puţin probabil să se schimbe Pachetele de componente reutilizabile trebuie grupate după
Deci nu este avantajos să introducem stratul utilizarea aşteptată, Nu după:
de abstractizare funcţionalitate comună, nici
Exemplu: clasa String altă clasificare arbitrară.
În aceste situaţii, se foloseşte direct clasa concretă Clasele sunt de obicei refolosite în grupuri pe baza colaborării între
Ca în Java, C++ librării de clase
4. Principiul Segregării Interfeţelor (PSI) e.g. containere şi iteratorii asociaţi lor
Clienţii nu trebuie forţaţi să depindă de interfeţe pe care nu le Consecinţă – Pp. Reutilizării Comune
folosesc. R. Martin, 1996 Trebuie să grupăm într-un pachet clase ce pot fi refolosite
Mai multe interfeţe specializate pe fiecare client sunt mai bune împreună;
decât o interfaţă de interes general Altfel vom depinde de clase ce nu au legătură cu aplicaţia noastră,
Consecinţă: şi va trebui să re-compilăm aplicaţia la fiecare nouă versiune a
impactul modificărilor unei interfeţe este mai mic dacă pachetului de care depindem (chiar dacă versiunea modifică doar
interfaţa este mai mică acele clase de care noi nu avem nevoie)
poluarea interfeţelor 7. Principiul Închiderii Comune (PÎC)
Design-ul de nivel înalt Clasele unui pachet trebuie să fie închise faţă de aceleaşi tipuri de
Când vorbim de sisteme pe scară largă modificări. O modificare ce afectează pachetul, afectează toate
> 50000 Lines Of Code (C) clasele acelui pachet.
Echipe de dezvoltatori, nu un singur individ Adică?
Clasele sunt un mecanism de valoare dar insuficient Clasele care se modifică împreună trebuie grupate la
prea mărunte pentru organizarea design-ului unui un loc
sistem de dimensiuni mari Scop: limitarea dispersării modificărilor între pachetele
distribuite
 Modificările trebuie să modifice un număr
minim de pachete distribuite
Relaţia cu PDeschis- Închis
Clasele unui pachet trebuie să fie coezive
Pentru un anumit tip de modificare, fie se modifică toate
clasele unei componente, fie nu se modifică nici una
Refolosire vs. Mentenanţă
PER şi PRC fac viaţa mai uşoară reutilizatorului
pachete foarte mici
PÎC face mentenanţa mai uşoară
pachete mari
Pachetele se pot modifica
iniţial, este important PÎC
Mai apoi, când dorim să reutilizăm: PER, PRC