Principii Poo

49
OOP 1 Concepte si Principii POO de baza UML - review

description

Principii OOP

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