Documente Academic
Documente Profesional
Documente Cultură
baza
UML - review
OOP
Paradigma POO(2)
Concepte:
1.
2.
3.
Clasa
- implementare a unui TAD
Obiect
= instanta a unei clase
Metoda = implementarea unei operatii din interfata TAD
(mesaj = apel al metodei > interactiune intre obiecte)
Caracteristici:
1.
2.
3.
Lizibilitate
Usor de inteles -> de depanat, intretinut
Reutilizabilitate
!!! Doar daca programele sunt construite respectand principiile POO!!!
OOP
Reutilizabilitate
prin instantiere (trivial)
prin compozitie (agregare) ( hasa relationship)
Shape
Window
Rectangle
RoundRectangle
OOP
Reutilizabilitate(2)
is - a relationship
Substitutie pura!
Shape* s=new Circle();
s->draw();
Suprascriere (Overriding)
OOP
Suprascriere Supraincarcare
Exemplu:
class Shape{
void draw();
};
class Circle: public Shape{
\\
public:
void draw(); \\ overriding
void draw (int width);
\\
\\ overloading
};
OOP
Reutilizabilitate (3)
is-like-a relationship
Adaugare de functionalitate
Shape* s=new Triangle();
s->draw();
//s->FlipVertical();
((Triangle*)s)->FlipVertical();
//possible using cast!
//downcasting
Reutilizabilitate(4)
interfata = multimea mesajelor (cererilor) care pot fi trimise
clasa = implementarea unui tip
subtip
(substitutie: instanta unui subtip in locul unei instante a tipului)
Mostenire de interfata Mostenire de clasa (reutilizare cod)
Mostenire de clasa defineste implementarea unui obiect folosind
implementarea unui alt object
Mostenire de interfata descrie cazurile in care un obiect poate fi
utilizat in locul unui alt obiect
OOP
Polimorfism
Principiul Substitutiei
Un obiect al clasei derivate
poate apare oriunde
un obiect clasei de baza
este asteptat
Exemplu C++:
Shape* s1 = new Circle();
Shape* s2 = new Triangle();
s1->draw(); s2->draw();
Shape *x[2];
x[0]=new Triangle();x[1]=s1;
for (int i=0; i<2; i++)
x[i]->draw();
OOP
10
Polimorfism =
proprietatea unei entitati de a reactiona diferit in functie de starea sa.
Este posibil folosind legarea dinamica !
OOP
11
Exemplu
void Move(Shape& s, int dx, int dy){
// !!! Reference type
s.erase();
s.move(dx,dy)
s.draw();
}
// . . .
Circle c(10,10,50);
Triangle t(10,10, 20,20, 50,50);
Move(c,2 ,2);
Move(t, 4, 4);
OOP
12
Mecanismul C++
Shape
VPTR
PTR_draw
x
y
PTR_erase
Point::draw()
Point
VMT_for_Circle
c:Circle
VPTR
PTR_draw
x
y
r
PTR_erase
Circle::draw()
OOP
Circle
13
Construieste clasele cat mai atomic posibil; adica, fiecare clasa trebuie sa
aiba un scop singur si clar (in general implementarea unui TAD).
In general o metoda :
schimba starea objectului apelant, folosindu-se de starea anterioara,
furnizeaza informatii despre stare.
Pastreaza totul private pe cat posibil, si lasa doar interfata clasei public.
(modifica starea doar prin mesaje!!!!!!)
14
OOP
15
16
Example
public class UserSettingService
{
public void changeEmail(User user)
{
if (checkAccess(user))
{
//Grant option to change
}
}
public boolean checkAccess(User user)
{
//Verify if the user is valid.
}
}
17
Principiul Open/Closed
Principiu:
Entitatile de programare (clase, module, functii) trebuie sa fie deschise pentru
extindere, dar inchise la modificare.
Consecinta:
=> O asemenea entitate poate permite modificarea comportamentului sau fara
modificarea codului sau sursa
Doua variante:
Ambele se bazeaza pe mostenire
Au scopuri, tehnici si rezultate diferite
OOP
18
19
OOP
20
Example
public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator)<br />
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
OOP
21
OOP
22
Correct adaptation
/**
* Abstract Validator class
* Extended to add different
* validators for different loan type
*/
public abstract class Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
extends Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
OOP
23
OOP
24
Principiul Substitutiei
LSPThe Liskov Substitution Principle
Principiul:
Functiile care folosesc pointeri sau referinte catre clase de baza trebuie sa
poata folosi obiecte(instante) ale claselor derivate fara sa le stie
anterior!
Barbara Liskov first wrote it as follows:
What is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behavior of P is unchanged when o1
is substituted for o2 then S is a subtype of T.
OOP
25
Principiul:
Clientii nu trebuie sa fie fortati sa depinda de interfete pe care nu le
folosesc!
Fat interfaces nu sunt specifice unui singur client/responsabilitate.
Fat interfaces conduc la cuplari neadecvte intre clienti.
Solutii:
Folosirea sablonului ADAPTER
Fie prin delegare (object form) or
Mostenire multipla (class form),
Rezultat:
interfetele sunt separate in clase abstracte de baza.
OOP
26
Exemplu
OOP
Principiul:
Modulele de nivel inalt nu trebuie sa depinda de modulele de nivel
scazut! Ambele trebuie sa depinda doar de abstractizari!
Abstractizarile nu trebuie sa depinda de detalii. Detaliile trebuie sa
depinda de abstractizari!
Explicarea termenilor
inversion.
In mod uzual (ex. in Analiza si Proiectarea Structurata) se
creeau module care depindeau de module de nivel mai scazut.
Se inverseaza structura de dependenta!
Necesitate: Dependenta este tranzitiva .
OOP
28
Layers
OOP
29
Layering
According to Booch , ...all well structured object-oriented architectures have
clearly-defined layers, with each layer providing some coherent set of
services though a well-defined and controlled interface.
A naive interpretation of this statement might lead a designer to produce a
structure similar to Figure 1. While this may look appropriate, it has the
insidious characteristic that the Policy Layer is sensitive to changes all the
way down in the Utility Layer.
Dependency is transitive . The Policy Layer depends upon something that
depends upon the Utility Layer, thus the Policy Layer transitively depends
upon the Utility Layer. This is very unfortunate.
Figure 2 shows a more appropriate model. Each of the lower level layers are
represented by an abstract class. The actual layers are then derived from
these abstract classes. Each of the higher level classes uses the next
lowest layer through the abstract interface.
Thus, none of the layers depends upon any of the other layers. Instead, the
layers depend upon abstract classes. Not only is the transitive dependency
of Policy Layer upon Utility Layer broken, but even the direct dependency of
Policy Layer upon Mechanism Layer is broken.
OOP
30
Example
OOP
31
Analiza si Proiectare
1. Descoperirea obiectelor
2. Asamblarea obiectelor
3. Constructia sistemului
4. Extensia sistemului
5. Reutilizarea obiectelor
OOP
32
http://www.omg.org/cgi-bin/doc?ptc/2003-08-02
OOP
33
UML(2)
34
UML(3)
OOP
35
UML(4)
OOP
36
UML(5)
OOP
37
Autor
Persoana
Computer
1..*
Detine
0..*
Este detinut de
Masina
Asociere navigabila
Detine
Persoana
OOP
0..*
Masina
38
Contine
Figura
FiguraId
Asociere -OR
Company
0..*
0..*
Contract
0..*
de asigurare
0..*
de asigurari
(or)
1..*
1..*
Persoana
Companie
OOP
39
Femeie
Barbat
OOP
40
Echipa
Formata din
Jucator
1..*
Agregare compozitie
TitleBar
Window
*
OOP
Menu
41
Persoana
Student
OOP
42
Class A
Class B
OOP
43
Class stereotypes
OOP
44
Properties
OOP
45
Inner classes
OOP
46
OOP
47
OOP
48
UML(6)
Use-case diagrams
Collaboration diagrams
Sequence diagrams
OOP
49