Programare Orientata spre Obiecte - ERASMUS...

Programare Orientata spre Obiecte

(Object-Oriented Programming)

a.k.a. Programare Obiect-Orientata

2011 - 2012

UPB - Facultatea ETTI - Curs POO - an II - seria E

UPB - ETTI - Curs POO - an II - seria E 12.10.2011 1

Titular curs: Eduard-Cristian Popovici

Suport curs: http://discipline.elcom.pub.ro/POO-Java/

http://discipline.elcom.pub.ro/POO-Java/





UPB - ETTI - Curs POO - an II - seria E 2

Orientarea spre Obiecte (OO)

Orientarea spre

modelarea (abstractizarea) informatica a realitatii

entitati bazate pe responsabilitati (roluri)

incapsulare duala (a structurilor de date si de comportament)

mentinerea si ascunderea unei stari interne

colaborare intre entitati (comunicare prin mesaje, interactiune

sociala)

definirea unor interfete contractuale, componente black-box, etc.

1.3. Caracteristicile si principiile abordarii OO U

rmeaza

1. Introducere in abordarea orientata spre obiecte (OO)

1.3. Caracteristicile si principiile abordarii OO

Structura cursului



Programul (sistemul software) orientat spre obiecte

– reprezinta un model informatic

– al unei parti din lumea reala

– elementele care compun modelul

– sunt construite prin analogie cu entitati care apar in lumea reala

(obiecte reale, concepte)

– sunt numite obiecte software

– trebuie reprezentate in limbajul de programare

Care sunt constructiile software care permit reprezentarea obiectelor software

(similare) in limbaje de programare?

Modelarea si abstractizarea OO


studentX

studentA

studentY

studentB studentZ


Ca si in cazul obiectelor si conceptelor din lumea reala

– obiectele software pot fi categorisite (clasificate)

– categoriile (numite clase de obiecte) corespunzand

– diferitelor responsabilitati pe care le au

– sau diferitelor roluri pe care le joaca entitatile din lumea reala

– din care sunt construite prin analogie obiectele software

Clasele

– sunt constructiile software care

– reprezinta obiectele software care au responsabilitati / roluri similare

Clasificarea OO – entitati bazate pe responsabilitati (roluri)



Clasa (obiectelor software)

– este o constructie software complexa

– asemanatoare structurilor de date din C (struct)

– evoluata din ADT (concretizare a ADT)

– si astfel tip de date cu incapsulare duala

– care descrie intr-o forma abstracta

– toate obiectele software de un tip particular

(care au responsabilitati / roluri similare)

Clasificarea OO – abstractizarea multimilor (AM) de obiecte


studentX

studentA

studentY

studentB

Student

Clasa (categorie, tip)

AM (AOO)

obiecte software


Clasa fiind o constructie software evoluata din ADT

– realizeaza o incapsulare cu ascundere a detaliilor duala

– a informatiilor (datelor)

– regrupand elementele de date

– numite atribute sau variabile membru

– implicit CU ascunderea detaliilor (datelor, informatiilor)

– a comportamentului

– regruparea elementelor de comportament

– numite operatii sau functii membru

– implicit CU ascunderea detaliilor (implementarii)

– «transmite» obiectelor aceasta incapsulare cu ascundere a detaliilor duala


Clasificarea OO – incapsularea duala cu ascunderea detaliilor

!


Incapsularea oferita de clase (si obiecte) este o forma de incapsulare duala

semnaturi

operatii

Interfata (setul de semnaturi

ale operatiilor) – ideal este

publica, vizibila, accesibila

Reprezentarea datelor si implementarea (setul

de atribute si setul de implementari ale operatiilor)

– ideal sunt private, ascunse, inaccesibile

atribute

(variabile interne

ascunse)

comportament

(implementare operatii)

asociat atributelor

Clasa (obiect)

Incapsularea duala cu ascunderea detaliilor


INCAPSULARE DUALA

(INFORMATII SI

COMPORTAMENT)




Incapsularea OO – oferita de clase si obiecte

– inseamna ascunderea detaliilor interne

– reprezentarea datelor (set de atribute)

– si implementarea (set de coduri ale operatiilor)

in spatele unei interfete publice (set de semnaturi ale operatiilor)

Exemplu

in Java




Exemplu

in Java


Obiectele si conceptele sunt categorisite / clasificate

– atat in lumea reala cat si in cea informatica (software)

– pe baza caracteristicilor esentiale pe care le au (rezultate in urma

abstractizarilor)

– atribute – elemente de date, variabile interne care caracterizeaza

obiectele

– operatii – elemente de comportament, proceduri care pot fi efectuate

asupra atributelor

Clasele

– reprezinta obiecte software care au caracteristici esentiale (atribute si

operatii) similare

studentX

nume=“Xulescu”


Clasificarea OO – incapsularea duala cu ascunderea detaliilor

Atribut

Obiect


Ansamblul valorilor atributelor unui obiect la un moment dat

– reprezinta starea interna obiectului

Atributele

– sunt astfel “variabilele de stare” ale obiectului

– sunt prin natura lor private, ascunse, inaccesibile

– si dau astfel starii obiectelor

– calitatea de a fi privata, ascunsa, inaccesibila direct

– ea putand fi obtinuta din exterior doar indirect (controlat)

– prin intermediul apelurilor la operatii

Mentinerea si ascunderea unei stari interne

studentX

note = {7,9,8,9}


Starea interna

la un moment dat

Obiect


Starea unui obiect poate varia in timp

– ca urmare a comportamentului

– care este rezultatul executiei operatiilor

– prin apeluri venite de la alte obiecte


studentX

note = {7,9,8,9}


Starea interna

la un moment dat

(initial)

timp







studentX

note = {7,9,8,9}


Starea interna

la un moment dat

(initial)

timp

Executia

operatiei

studentX

addNota(8)

addNota()

Apel venit

de la alt obiect






Mentinerea si ascunderea unei stari interne sunt calitati noi ale programelor

– introduse de orientarea spre obiecte


studentX

note = {7,9,8,9,8}

studentX

note = {7,9,8,9}


Starea interna

la un moment dat

(initial)

Starea interna

dupa executia

operatiei

Executia

operatiei

studentX

addNota(8)

addNota()

Apel venit

de la alt obiect


In lumea reala

– sarcinile sunt realizate in colaborare intre entitati diverse

Abordarile actuale

– OOP – programarea orientata spre obiecte (derivata din conceptul ADT)

– CBD – dezvoltarea bazata pe componente (black box)

– SOA – orientarea spre servicii a arhitecturilor

imita modelele sociale, colaborative

Colaborarea intre entitati – comunicarea prin mesaje



Obiect utilizator

Mesaj

Legătură

Interacţiune a obiectelor

Comunicaţie între obiecte

Colaborare între obiecte

Decuplare intre obiecte

Declanşare

(executie)

Referinţă

Obiect tinta comportament global

al sistemului

(scenarii =

secvenţe de mesaje =

colaborări între obiecte) Operaţie

Comportamentul si operatiile (functiile, procedurile) in abordarea OO

– se reprezinta prin forme de colaborare (comunicare, interactiune)

– intre obiectele ce compun programul (sistemul software)




Obiect utilizator

Mesaj

Legătură

Interacţiune a obiectelor

Comunicaţie între obiecte

Colaborare între obiecte

Decuplare intre obiecte

Declanşare

(executie)

Referinţă

Obiect tinta

comportament global

al sistemului

(scenarii =

secvenţe de mesaje =

colaborări între obiecte) Operaţie

Operatiile (functiile, procedurile) in abordarea OO

– sunt unitati de comunicare (interactiune)

– numite mesaje




Constructia unui program de calcul (sistem software)

– este o secventa de iteratii de tip divizare-reunire, fiind necesare:

– descompunerea (analiza) pentru

– a intelege problema si

– a putea formula o conceptie a solutiei

– compunerea (sinteza) pentru

– a construi solutia (a materializa, a realiza efectiv conceptia)

Abordarea orientata spre obiecte a dezvoltarii programelor

Descompunere

(funcţională / OO)

Analiză

(funcţională / OO) Construcţie a

componentelor

Produs

Compunere

(integrare)

Specificatii





Abordarea orientata spre obiecte (OO)

– propune descompunerea bazată pe

– responsabilitati si delegare de responsabilitati (nu doar functionala)

– integrarea a ceea ce este (structural) şi ceea ce face (comportamental)

sistemul (nu doar a ceea ce face)

Cuplajul intre obiecte

– este obtinut prin trimiterea de mesaje (apelurile de operatii)

– si astfel dinamic si slab

Buton

Cabină Uşă

Bec

Aprindere

Deschidere

Deplasare

Actionare

Lift




f1

f2

f3

v1

v2

u1

u2

u3

w1

w2

w3

g1

g2

h1

h2 o1 : Clasa1

o2 : Clasa2

o3 : Clasa3

Modelul colaborativ OO in general

– operatiile sunt mesaje

schimbate intre obiecte

(suportul colaborarii)




f1

f2

f3

v1

v2

u1

u2

u3

w1

w2

w3

g1

g2

h1

h2 Clasa1

Clasa2

Clasa3

Modelul colaborativ OO in Java

– obiectele fiind create

dinamic sunt accesate

prin referinte

o1

Referinta

catre obiect

Obiectul propriu-zis

(de tip Clasa1)

Obiectul

propriu-zis

(de tip Clasa2)

Obiectul

propriu-zis

(de tip Clasa3) o2

o3




Exemple de cod Java

System.out.println(..);

System = clasa Java din pachetul java.lang (importat implicit)

out = atribut public static al clasei System

(variabila partajata de toate obiectele clasei System)

= referinta catre obiect din clasa PrintStream

println(..) = metoda a obiectelor clasei PrintStream

d.p.d.v.

structural

d.p.d.v. al clasificarii




Exemple de cod Java


// clasa Java din pachetul java.lang

public class System {

// atribut public static al clasei System

// obiect din clasa PrintStream

public static PrintStream out;

// .. restul codului clasei System

}

exit()

gc()

out

System

in

Clasa utilitara care

incapsuleaza facilitatile

portabile ale sistemelor de

operare (apeluri “sistem”

cum e exit(), console I/O)




Exemple de cod Java


// clasa Java din pachetul java.io

public class PrintStream {

// metoda a obiectelor clasei PrintStream

public void println(..) {

// .. codului metodei println()

}

// .. restul codului clasei PrintStream

}

out

print(..)

println(..)

PrintStream

Obiect al unei clase

flux de iesire care

incapsuleaza fluxul de

date catre consola

standard de iesire)




exit()

gc()

out

print(..)

println(..)

read()

System

PrintStream

InputStream

in

Exemple de cod Java

System.out.println(i);

System = clasa Java

out = atribut public static al clasei System

= obiect din clasa PrintStream

println() = metoda a obiectelor clasei PrintStream




Exemple de cod Java

int i = System.in.read();

System = clasa Java din pachetul java.lang (importat implicit)

in = atribut public static al clasei System

(variabila partajata de toate obiectele clasei System)

= referinta catre obiect din clasa InputStream

read() = metoda a obiectelor clasei InputStream

d.p.d.v.

structural

d.p.d.v. al clasificarii




Exemple de cod Java


// clasa Java din pachetul java.lang

public class System {

// atribut public static (partajat de obiecte) al clasei System

// obiect din clasa InputStream

public static InputStream in;

// .. restul codului clasei System

}

exit()

gc()

out

System

in




Exemple de cod Java


// clasa Java din pachetul java.io

public class InputStream {

// metoda a obiectelor clasei InputStream

public int read() {

// .. codului metodei read()

}

// .. restul codului clasei InputStream

}

read()

InputStream

in

Obiect al unei clase

flux de intrare care

incapsuleaza fluxul de

date dinspre consola

standard de intrare)




exit()

gc()

out

print(..)

println(..)

read()

System

PrintStream

InputStream

in

Exemple de cod Java


System = clasa Java

in = atribut public static al clasei System

= obiect din clasa InputStream

read() = metoda a obiectelor clasei InputStream



Abordarea orientata spre obiecte vs abordarea procedurala

Abordarea

procedurala

Abordarea OO

Partajarea datelor si responsabilitatilor

creeaza probleme



Abordarea orientata spre obiecte vs abordarea procedurala

Abordarea

procedurala

Abordarea OO

Partajarea datelor si responsabilitatilor

creeaza probleme

Separarea rolurilor

/ responsabilitatilor

si protectia datelor


Programarea ca rezolvare de probleme



Proiectarea

solutiei Analiza

problemei Implementarea

(concretizarea) solutiei

Domeniu al

realitatii

Entitate reala

Incapsulare duala cu ascunderea

datelor si a comportamentului

(clasa de obiecte)

Constructii ale unui

limbaj de programare OO

Modelare /

Abstractizare

Transformare constructii

teoretice in constructii ale

unui limbaj


Orientarea spre obiecte (OO) este astfel o orientare spre

– modelarea / abstractizarea (A) informatica a realitatii (in obiecte si clase)

– entitati bazate pe responsabilitati / roluri (clasele si obiectele)

– incapsularea (E) duala – a reprezentarii datelor si a comportamentului (in

obiecte si clase) cu limitarea accesului

– mentinerea si ascunderea unei stari interne (in obiecte)

– colaborare “sociala” intre entitati / comunicare prin mesaje (intre obiecte)

– definirea unor interfete contractuale (ale claselor) / componente black-box

In plus, OO utilizeaza si concepte mai avansate

– generalizarea claselor in superclase si specializarea claselor in subclase

prin mostenire (I)

– polimorfismul (P) – selectia dinamica a comportamentului operatiei

– bazata pe pozitia in ierarhia de clase a obiectului


“A P I E”


Orientarea spre obiecte (OO) inseamna

– modelarea / abstractizarea (A) realitatii

– entitati cu responsabilitati / roluri

– incapsularea (E) duala (date+comportament) cu limitarea accesului

– mentinerea si ascunderea unei stari interne

– colaborare intre obiecte / comunicare prin mesaje

– interfete contractuale / componente black-box

Concepte avansate

– generalizarea si specializarea claselor in ierarhii prin mostenire (I)

– polimorfismul (P)

– selectia dinamica a comportamentului operatiei

– bazata pe pozitia in ierarhia de clase a obiectului


“A P I E”


Principii ale proiectarii orientate spre obiecte (OOD)

Single Responsibility Principle (SRP)

A class should have only one reason to change (a single responsibility).

Open Close Principle (OCP)

Software entities like classes, modules and functions should be open for

extension but closed for modifications.

Liskov’s Substitution Principle (LSP)

Derived types must be completely substitutable for their base types.

Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they don’t use.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should

depend on abstractions.

Abstractions should not depend on details.

Details should depend on abstractions.


http://www.ictian.com/2011/07/object-oriented-principles/




A class should have only one reason to change.

Fiecare clasa trebuie sa indeplineasca exact o responsabilitate.

O clasa continand “N” responsabilitati trebuie separata in “N” clase

One or more work orders is associated with a specific customer

The purchase order is associated with a vendor

Each line item on the purchase order reflects a part purchased for that vendor

A part in the inventory system may be available from several vendors

Each vendor has its own cost for the part

The inventory system manages its own "cost" of the part

The inventory cost is adjusted using a moving average: (4*oldCost + newCost)/5

Parts are designated as taxable or not

Each PO line item is purchased either for inventory or as a part needed for a work order

When the vendor invoice comes in, additional charges, such as shipping, hazmat, etc., are added to the purchase order

The purchase order is closed when the purchased items are reconciled with the invoice

When the PO is closed, any parts that were purchased against a work order are automatically billed to the customer

Additional charges on the PO are added to the charge slip

Since line items on a purchase order may be associated with different work orders from different customers, the additional charges have to be fairly

distributed

The only rule that anyone can come up with regarding this distribution is to divvy up the charges based on the part cost in relation to the total

purchase order cost

Parts are billed on charge slips, which emulates the manual process being used

One or more charge slips are associated with one work order

Parts are assigned added to the PO by selecting the part out of inventory.

Only parts for the vendor from which the parts will be purchased should be available for addition to the PO

Customers get different discount rates and may or may not be taxable

Set de cerinte pentru un sistem

de automatic customer billing

http://www.codeproject.com/KB/cs/autp1.aspx




A class should have

only one reason to

change (single

responsibility).

Solutia: utilizand carduri

CRC (Class,

Responsibility,

Collaboration) putem

crea un model al

sistemului bazat pe

principiul SRP

Card

CRC



Software entities like classes, modules and functions should be open for extension

but closed for modifications.

Clasele trebuie sa poata fi usor extinse

fara a fi modificat codul existent


Clasa Account are cate o

operatie pentru fiecare

subtip al clasei AccountType

Adaugarea sau eliminarea

unei subclase a clasei

AccountType impune

adaugarea sau eliminarea

unei metode in clasa Account

Trebuie permisa

adaugarea/eliminarea noi

functionalitati sub forma de

operatii sau clase, cu minimum sau

fara modificari in codul existent

(pastrand cat mai mult posibil codul

existent nemodificat)

Code NOT

closed for

modification



Software entities like classes, modules and functions should be open for extension

but closed for modifications.

Solutia: clasa Account trebuie sa aiba operatii generice, care nu depind de

subtipurile clasei AccountType


OK!

OK!

Code NOT

closed for

modification


Liskov’s Substitution Principle (LSP)


Derived types must be completely substitutable for their base types.

Daca un cod client (context) utilizeaza o clasa de baza atunci o

referinta catre acea clasa de baza poate fi folosita catre obiecte dintr-

o clasa derivata fara a afecta functionalitatea codului client (context).

Codul client (context) care utilizeaza pointeri sau referinte catre o

clasa de baza trebuie sa fie capabil sa foloseasca obiecte din clase

derivate fara a conta (fara a sti) acest lucru.

clasa de baza

clasa

derivata

obiecte

din clasa

de baza

obiecte

din clasa

derivata





Clientii (codurile context) nu trebuie fortati sa implementeze interfete pe

care nu le utilizeze

In loc de a proiecta

o interfata cu multe

operatii (fat), trebuie

proiectate mai multe

interfete mai mici

bazate pe grupuri

de operatii

Fiecare interfata mica

urmand sa serveasca

un sub-modul A typical “fat”

interface





Solutia: mai multe interfete mai mici bazate pe grupuri de operatii

OK!






Abstractions should not depend on details. Details should depend on

abstractions.

Componentele de nivel inalt trebuie decuplate de componentele de

nivel redus

Trebuie permisa reutilizarea diferitelor componente de nivel redus

Inlocuirea componentelor de nivel redus trebuie obtinuta fara

schimbari in componentele de nivel inalt

Majoritatea systemelor software actuale sunt organizate ierarhic (in niveluri).

In implementarea naiva a unui sistem ierarhic nivelurile inalte (UI /

Business) depind de cele reduse (Business / Database)

Problema este ca schimbari in

componentele inferioare le

afecteaza pe cele de nivel inalt






Abstractions should not depend on details. Details should depend on

abstractions.

Solutia: inversarea dependentelor

– componentele de nivel inalt

depinzand doar de interfete

abstracte (nemodificabile),

implementate de componentele

de nivel redus

OK!

Programare Orientata spre Obiecte - ERASMUS...

Documents

Transcript of Programare Orientata spre Obiecte - ERASMUS...