Concepte si Principii POO de
baza
UML - review
OOP
Paradigma POO (1)
Necesitatea:
Spatiul problemei Spatiul solutiei
Modelul problemei Modelul solutiei
POO ofera instrumente eficiente pentru reprezentare
POO permite rezolvarea problemei in termenii problemei,
nu in termeni specifici modelului calculatorului pe care
se executa solutia.
Obiect = reprezentarea unui element din spatiul problemei
(def. generala)
in spatiul solutiei
Orice obiect are o stare
Orice obiect are o interfata
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.
Incapsulare (date + operatii)
ascunderea informatiei protectia informatiei consistenta datelor
2.
Mostenire reutilizarea codului
3.
Polimorfism = capacitatea unei entitati de a reactiona diferit in
functie de starea sa.
OOP
Avantaje ale POO
Abstractizare (de nivel inalt)
Un obiect poate fi utilizat fara a se cunoaste reprezentarea sa interna
Modularitate & Modificabilitate
Codul sursa corespunzator unui obiect poate fi scris si intretinut
independent de codul sursa corespunzator altor obiecte.
O clasa poate fi usor schimbata fara a se modifica alte clase.
Biblioteci de clase
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
prin mostenire (is-a or is-like-a relationship)
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
Noile functii nu sunt
accesibile direct prin clasa de baza.
OOP
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
Legare Statica si Dinamica
Legarea dintre numele unei functii si codul sau se poate face:
- la compilare => legare statica
- in timpul executiei => legare dinamica
Legare dinamica (Late Binding)
Daca se trimite un mesaj unui obiect,
codul corespunzator se determina doar
la momentul executie lui.
( posibil doar pentru referinte si pointeri)
Metodele virtuale permit legarea dinamica
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++
VMT Virtual Method Table
VMT_for_Point
p:Point
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
Cateva reguli de programare!
Problemele de proiectare pot fi simplificate prin introducerea unui nou nivel
de indirectare conceptuala.
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!!!!!!)
Nu folosi mostenire multipla decat daca este absolut necesar!
Alege intre compozitie si mostenire
Cum? Daca e nevoie de upcast mostenire,
altfel compozitie
OOP
14
SOLID Principii de proiectare
(The Principles of OOD).
SOLID stands for:
Single Responsibility principle (SRP)
Open Closed principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation principle (ISP)
Dependency Inversion principle (DIP)
OOP
15
Single Responsibility principle (SRP)
Principiu: Trebuie sa existe doar o motivatie pentru a schimba o clasa!
motivatie pentru schimbare <-> responsabilitatea unei clase.
Fiecare resposabilitate va reprezenta o axa pentru schimbare.
Este similar cerintei de a creea clase cu coeziune ridicata.
O responsabilitate poate fi implementata folosind mai multe metode din aceeasi
clasa.
DE ce?
atunci cand se cere schimbarea unei functionalitati nu putem fi sigur de impactul
asupra altora care sunt implementate de aceeasi clasa
Necesar testarea tuturor caracteristicilor depenedente
Contraargument:
Daca avem teste automate si numarulmde teste nu este mare atunci numarul de
verificari nu este mare.
Raspuns:
Per global aceste verificari se acumuleaza si creste timpul de rezolvare. Codul ar
deveni fragil si rigid.
Solutie (de refactorizare):
Diviziunea functionalitatilor unei clase in clase diferite, care respecta fiecare
SRP.
OOP
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.
}
}
What if you would want to reuse the
checkAccess code at some other place OR
you want to make changes to the way
checkAccess is being done OR you want to
make change to the way email changes are
being approved.
One way to correct this is to decompose the
UserSettingService into UserSettingService
and SecurityService. And move the
checkAccess code into SecurityService.
public class UserSettingService
{
public void changeEmail(User user)
{
if(SecurityService.checkAccess(user))
{
//Grant option to change
}
}
}
public class SecurityService
{
public static boolean checkAccess(User user)
{
//check the access.
}
}
OOP
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
Important pentru activitatea de productie
activitate de intretinere: code reviews, unit tests, si altele):
Daca se respecta acest principiu nu este nevoie de acest effort.
Doua variante:
Ambele se bazeaza pe mostenire
Au scopuri, tehnici si rezultate diferite
OOP
18
Principiul OCP al lui Meyer
(MeyersOpen/Closed Principle)
Bertrand Meyer, Object Oriented Software Construction. 1988
Odata ce implementarea unei clase a fost terminat, nu se permite
modificarea codului asociat decat pentru a corecta greseli.
Caracteristicile noi vor trebui introduse prin crearea de noi clase!
Clasele noi pot folosi clasa origina prin mostenire.
Nu este obligatorie folosirea aceleiasi interfete.
Aceasta cerinta implica refolosirea implementarii (mostenirea de
clasa; refolosirea codului)
Implementarea existenta este inchisa pentru modificari si noile clase
nu trebuie sa implementeze interfata existenta.
OOP
19
Principiul OCP Polimorfic
Programarea bazata pe interfete
Multiple implementari ale aceleiasi interfete
Substitutie polimorfica
Diferente fata de varianta lui Meyer:
Se recomanda mostinerea din clase abstracte/ interfete
Refolosirea interfetelor(tipului).
Interfata existenta este inchisa la modificari si noile implementari trebuie
doar sa implementreze acea interfata.
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
Incorrect adaptation - violates the OCP
public class LoanApprovalHandler
{
public void approvePersonalLoan
(PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan
(VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
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.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/
public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
OOP
23
Reguli care conduc la respectarea OCP
Declararea tuturor variabilelor membru private => accesul la ele
doar via (getters).
Evitarea operatiilor de typecasts la runtime.
Acest lucru conduce la un cod fragil si dependent de clasele
considerate la momentul dezvoltarii.
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 Segregarii Interfetelor
The Interface Segregation Principle (ISP)
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
Separation through Delegation
Consider a security system. In this system there
are Door objects that can be locked and
unlocked, and which know whether they are
open or closed.
TimedDoor needs to sound an alarm when the
door has been left open for too long. In order to
do this the TimedDoor object communicates with
another object called a Timer.
OOP
Separation through Multiple
Inheritance
27
Principiul inversarii dependentei DIP
The Dependency Inversion Principle
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
Cine va folosi sistemul?" (pentru a descoperi actorii)
Ce pot face acesti actori cu sistemul?"
Cum poate sistemul reactiona daca altcineva face acestea?"
(pentru a descoperi variatiile)
Ce probleme pot apare in sistem?"
(pentru a descoperi exceptiile)
1. Descoperirea obiectelor
2. Asamblarea obiectelor
3. Constructia sistemului
4. Extensia sistemului
5. Reutilizarea obiectelor
OOP
32
UML (Unified Modeling Language)
UML este un limbaj standard pentru specificarea,
vizualizarea, constructia si documentarea artefactelor
sistemelor software.
UML notatie standard pentru arhitecturile software
Online UML Resurse
Rational Software
-- UML Resource Center (http://www-306.ibm.com/software/rational/uml/),
The Object Management Group http://www.uml.org/
http://www.omg.org/cgi-bin/doc?ptc/2003-08-02
OOP
33
UML(2)
Tipuri de date: Integer, Real, String, Character, Boolean
OOP
34
UML(3)
OOP
35
UML(4)
OOP
36
UML(5)
OOP
37
Exemple UML - Asociere
Asociere simpla
Foloseste
Autor
Persoana
Computer
1..*
Detine
0..*
Este detinut de
Masina
Asociere navigabila
Detine
Persoana
OOP
0..*
Masina
38
Exemple UML - Asociere
Asociere calificata
Canvas
Contine
Figura
FiguraId
Asociere -OR
Company
0..*
0..*
Contract
0..*
de asigurare
0..*
de asigurari
(or)
1..*
1..*
Persoana
Companie
OOP
39
Exemple UML - Asociere
Asociere de tip clasa
Casatorie
Femeie
Barbat
Clasa de tip asociere
este folosita pentru a adauga informatie in plus legaturii.
OOP
40
Exemple UML - Agregare
Agregare simpla
Echipa
Formata din
Jucator
1..*
Agregare compozitie
TitleBar
Window
*
OOP
Menu
41
Exemple UML Generalizare/Specializare
Persoana
Student
OOP
42
UML Examples -Dependenta
Class A
Class B
Clasa A depinde de clasa B.
O modificare a clasei B poate conduce la modificari in
clasa dependenta.
OOP
43
Class stereotypes
OOP
44
Properties
OOP
45
Inner classes
OOP
46
Deep copy - example
OOP
47
OOP
48
UML(6)
Use-case diagrams
Collaboration diagrams
Sequence diagrams
OOP
49
