Principii Poo
-
Upload
simona-danciu -
Category
Documents
-
view
115 -
download
2
description
Transcript of Principii Poo
-
OOP 1
Concepte si Principii POO de
baza
UML - review
-
OOP 2
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 carese 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 3
Paradigma POO(2)
Concepte:
1. Clasa - implementare a unui TAD
2. Obiect = instanta a unei clase
3. 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 4
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 intretinutindependent 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 5
Reutilizabilitate
prin instantiere (trivial)
prin compozitie (agregare) ( hasa relationship)
prin mostenire (is-a or is-like-a relationship)
Window Shape
RoundRectangleRectangle
-
OOP 6
Reutilizabilitate(2)
is - a relationship
Substitutie pura!
Shape* s=new Circle();s->draw();
Suprascriere (Overriding)
-
OOP 7
Suprascriere Supraincarcare
Exemplu:class Shape{
void draw();};
class Circle: public Shape{\\ public:
void draw(); \\ overriding
void draw (int width); \\ overloading\\
};
-
OOP 8
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 9
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 folosindimplementarea unui alt object
Mostenire de interfata descrie cazurile in care un obiect poate fiutilizat in locul unui alt obiect
-
OOP 10
Polimorfism
Principiul Substitutiei
Un obiect al clasei derivatepoate apare oriundeun obiect clasei de bazaeste 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; idraw();
-
OOP 11
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 12
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 13
Mecanismul C++
VMT Virtual Method Table
PTR_draw
PTR_erase
PTR_draw
PTR_erase
VMT_for_Point
VMT_for_Circle
Shape
Point
Circle
p:Point
VPTR
x
y
c:Circle
VPTR
x
y
r
Point::draw()
Circle::draw()
-
OOP 14
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 15
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 16
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 aceeasiclasa.
DE ce?
atunci cand se cere schimbarea unei functionalitati nu putem fi sigur de impactulasupra 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 ardeveni fragil si rigid.
Solutie (de refactorizare):
Diviziunea functionalitatilor unei clase in clase diferite, care respecta fiecareSRP.
-
OOP 17
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 thecheckAccess 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 UserSettingServiceand 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 18
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 19
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 permitemodificarea 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 declasa; refolosirea codului)
Implementarea existenta este inchisa pentru modificari si noile clase nu trebuie sa implementeze interfata existenta.
-
OOP 20
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 21
Example
public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
-
OOP 22
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 23
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 24
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 25
Principiul Substitutiei
LSPThe Liskov Substitution Principle
Principiul:
Functiile care folosesc pointeri sau referinte catre clase de baza trebuie sapoata folosi obiecte(instante) ale claselor derivate fara sa le stieanterior!
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 26
Principiul Segregarii InterfetelorThe 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 27
Exemplu
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.
Separation through Delegation
Separation through Multiple
Inheritance
-
OOP 28
Principiul inversarii dependentei DIPThe 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 29
Layers
-
OOP 30
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 31
Example
-
OOP 32
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 33
UML (Unified Modeling Language)
UML este un limbaj standard pentru specificarea, vizualizarea, constructia si documentarea artefactelorsistemelor 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 34
UML(2)
Tipuri de date: Integer, Real, String, Character, Boolean
-
OOP 35
UML(3)
-
OOP 36
UML(4)
-
OOP 37
UML(5)
-
OOP 38
Exemple UML - Asociere
Asociere simpla
Asociere navigabila
Persoana MasinaDetine
Este detinut de
1..* 0..*
Persoana MasinaDetine 0..*
Autor Computer
Foloseste
-
OOP 39
Exemple UML - Asociere
Asociere calificata
Asociere -OR
Canvas FiguraContine 0..*
FiguraId
Companyde asigurari
Contractde asigurare
CompaniePersoana
0..*
1..*1..*
0..*
(or)0..*
-
OOP 40
Exemple UML - Asociere
Asociere de tip clasa
Clasa de tip asociereeste folosita pentru a adauga informatie in plus legaturii.
Barbat Femeie
Casatorie
-
OOP 41
Exemple UML - Agregare
Agregare simpla
Agregare compozitie
Echipa JucatorFormata din
1..*
Window
Menu
TitleBar
*
-
OOP 42
Exemple UML Generalizare/Specializare
Persoana
Student
-
OOP 43
UML Examples -Dependenta
Clasa A depinde de clasa B.
O modificare a clasei B poate conduce la modificari in
clasa dependenta.
Class A Class B
-
OOP 44
Class stereotypes
-
OOP 45
Properties
-
OOP 46
Inner classes
-
OOP 47
Deep copy - example
-
OOP 48
-
OOP 49
UML(6)
Use-case diagrams
Collaboration diagrams
Sequence diagrams