Orientaci a objectes

Jordi Pradel Miquel Jose Raya Martos

PID_00171145

 FUOC PID_00171145

Orientaci a objectes

Cap part d'aquesta publicaci, incloent-hi el disseny general i la coberta, no pot ser copiada, reproduda, emmagatzemada o transmesa de cap manera ni per cap mitj, tant si s elctric com qumic, mecnic, ptic, de gravaci, de fotocpia o per altres mtodes, sense l'autoritzaci prvia per escrit dels titulars del copyright.

 FUOC PID_00171145

Orientaci a objectes

ndex

Introducci.................................................................................................. Objectius....................................................................................................... 1. Qu s l'orientaci a objectes?........................................................ 1.1. 1.2. 1.3. 2. Evoluci histrica dels llenguatges de programaci ................... Els llenguatges de programaci orientats a objectes ................... Anlisi orientada a objectes ........................................................

5 6 7 8 8 9 10 10 12 12 12 13 16 18 18 20 22 22 23 24 25 26 27 27 27 28 28 29 31 33 33

Classificaci i abstracci.................................................................. 2.1. 2.2. 2.3. Classificaci ................................................................................. Abstracci .................................................................................... Descripci de les classes d'objectes ............................................. 2.3.1. 2.3.2. 2.3.3. Atributs ........................................................................... Associacions ................................................................... Operacions .....................................................................

3.

Ocultaci d'informaci i encapsulament.................................... 3.1. 3.2. Ocultaci d'informaci ............................................................... Encapsulament ............................................................................

4.

Herncia i polimorfisme.................................................................. 4.1. 4.2. Herncia ....................................................................................... 4.1.1. 4.2.1. 4.2.2. Generalitzaci i especialitzaci ...................................... Classes abstractes i redefinici del comportament ........ Associacions polimrfiques ........................................... Polimorfisme ...............................................................................

5.

Cas prctic: un frum virtual........................................................ 5.1. Classificaci dels objectes ........................................................... 5.1.1. 5.1.2. 5.2. 5.3. Classes ............................................................................ Atributs ...........................................................................

Herncia ....................................................................................... Associacions .................................................................................

Resum............................................................................................................ Activitats...................................................................................................... Exercicis d'autoavaluaci........................................................................

 FUOC PID_00171145

Orientaci a objectes

Solucionari.................................................................................................. Glossari......................................................................................................... Bibliografia.................................................................................................

35 37 40

 FUOC PID_00171145

Orientaci a objectes

Introducci

Tal com hem vist al mdul "Introducci a l'enginyeria del programari", els programadors necessiten un llenguatge de programaci que els permeti escriure programes en termes de ms alt nivell d'abstracci del que la mquina pot executar per si mateixa. Un dels tipus de llenguatges de programaci ms importants sn els orientats a objectes. L'orientaci a objectes proposa fer una abstracci del problema que s'est intentant resoldre en lloc de fer-la de la mquina que finalment executar el programa. Grcies a aquest enfocament, resulta un paradigma molt til no solament per a la programaci sin tamb per a l'anlisi. Al llarg d'aquest mdul estudiarem com podem crear una descripci del mn real seguint el paradigma de l'orientaci a objectes i com aquesta descripci ens pot ajudar a fer anlisi de requisits per tamb en altres activitats del programari. Comenarem introduint l'orientaci a objectes i el context histric en el qual va nixer. A continuaci anirem veient, de manera progressiva, com podem fer servir el paradigma de l'orientaci a objectes per a descriure el mn real. Comenarem parlant de la classificaci i l'abstracci, mitjanant les quals estructurem la informaci en el que anomenarem classes, associacions, atributs i operacions i continuarem estudiant l'encapsulament, que ens permet ocultar informaci dins els objectes, i l'herncia i el polimorfisme, que ens permeten fer abstraccions ms potents. Finalment veurem com podem aplicar l'orientaci a objectes per a fer una descripci del mn real per mitj d'un cas prctic.

 FUOC PID_00171145

Orientaci a objectes

Objectius

L'objectiu principal d'aquest mdul s presentar el paradigma de l'orientaci a objectes i com es pot aplicar a activitats de l'enginyeria del programari diferents de la programaci. En concret, l'estudiant ha d'assolir els objectius segents:

1. Entendre els conceptes fonamentals de l'orientaci a objectes: classificaci, abstracci, ocultaci d'informaci, encapsulament, herncia i polimorfisme. 2. Saber com es poden descriure els objectes d'un sistema mitjanant l's de classes, atributs, operacions i associacions.

 FUOC PID_00171145

Orientaci a objectes

1. Qu s l'orientaci a objectes?

Un dels problemes comuns a tots els projectes de desenvolupament de programari s descriure la tasca que s'ha de dur a terme en un llenguatge que tant el programador com la computadora puguin entendre. Els llenguatges de programaci es van crear justament per aquest motiu.
El problema de la comunicaci

Vegeu tamb Al mdul "Introducci a l'enginyeria del programari" es tracten els diversos problemes comuns a tots els projectes de desenvolupament de programari.

Al mn de la programaci informtica s'ha intentat solucionar el problema creant nous llenguatges de programaci ms propers al llenguatge natural (el que fem servir les persones per a comunicar-nos entre nosaltres) i a la manera que tenim d'entendre la realitat que ens envolta.
Exemple de llenguatge assemblador A continuaci teniu un exemple de programa en llenguatge assemblador. No us preocupeu, que no cal entendre'l per a entendre la resta del mdul. .MODEL Small .STACK 100h .DATA msg db 'Hello, world!$' .CODE start: mov ah, 09h lea dx, msg int 21h mov ax,4C00h int 21h end start A continuaci teniu un exemple del mateix programa, aquest cop escrit en C. #include<stdio.h> int main(int arg_count,char ** arg_values) { printf("Hello World\n"); return 0; } I a continuaci en BASIC. 10 PRINT "Hello World"

 FUOC PID_00171145

Orientaci a objectes

1.1. Evoluci histrica dels llenguatges de programaci Ja sabem que els processadors poden entendre un conjunt limitat d'instruccions (l'anomenat codi mquina). Els primers llenguatges es limitaven a instruccions molts senzilles que es corresponien prcticament una a una amb les operacions que podia entendre el processador. Els llenguatges que implementen aquest paradigma es coneixen com a llenguatge assemblador. Els llenguatges fets en assemblador sn molt fcils d'interpretar per a la mquina, per sn molt complicats d'escriure i d'entendre per a les persones. Per aquest motiu, programar fent servir aquests llenguatges es fa molt feixuc i aquest enfocament noms s viable per a tasques molt concretes. De seguida es van anar elaborant llenguatges ms rics que permetien als programadors fer servir un llenguatge ms proper al llenguatge natural a l'hora de descriure les instruccions que ha de seguir el computador. s el cas de llenguatges com el BASIC, el COBOL o el C. Aquests llenguatges es coneixen com a llenguatges d'alt nivell perqu permeten expressar-se a un nivell d'abstracci ms alt que els llenguatges assembladors. Tamb es coneixen com a llenguatges procedimentals perqu es basen en la definici de procediments per a descompondre el problema que es vol tractar en unitats ms petites. Els llenguatges procedimentals eleven el nivell d'abstracci respecte als llenguatges assembladors creant una abstracci de la mquina sobre la qual s'executen, que entn instruccions ms abstractes que les que realment pot executar. 1.2. Els llenguatges de programaci orientats a objectes Al final dels anys seixanta els investigadors noruecs Ole-Johan Dahl i Kristen Nygaard, mentre treballaven en un programari de simulaci de vaixells, van decidir provar un enfocament diferent. En comptes de fer una abstracci de la mquina sobre la qual s'executaria el programa farien una abstracci del problema sobre el qual estaven treballant. Els seus programes, en comptes de tenir procediments i estructures de dades tindrien objectes, cadascun dels quals representaria un objecte del mn real; aix naixia el llenguatge Simula 67 i la programaci orientada a objectes. No va ser, per, fins al final dels setanta i comenaments dels vuitanta que el paradigma de l'orientaci a objectes es va popularitzar massivament, primer amb el llenguatge Smalltalk (creat per un grup d'investigadors dirigit per Alan Kay al mtic laboratori de Xerox a Palo Alto), desprs amb el C++ (creat per

 FUOC PID_00171145

Orientaci a objectes

Bjarne Stroustrup als no menys mtics laboratoris Bell d'AT&T el 1983) i finalment amb el Java, com un dels llenguatges ms populars actualment (creat per James Gosling a Sun Microsystems el 1995).

La diferncia fonamental dels llenguatgesorientatsaobjectes respecte als llenguatges procedimentals est en el fet que, en comptes de basar-se en all que la mquina pot entendre, es basen en all que les persones volem comunicar.

Aviat es va veure, per, que el fet que aquest paradigma se centrs en l'mbit del problema per resoldre i no pas en el de la soluci, el convertia en una bona eina no solament per a les tasques d'implementaci, sin tamb durant l'anlisi, ja que l'orientaci a objectes ens ofereix una manera de fer la descripci de qualsevol sistema fcilment traslladable a programari mitjanant els llenguatges de programaci orientats a objectes. 1.3. Anlisi orientada a objectes L'anlisi orientada a objectes consisteix a aplicar els conceptes i idees dels llenguatges orientats a objectes a l'anlisi de sistemes. Aix ens permetr fer servir un llenguatge similar durant les diferents etapes del desenvolupament. Aquest s de l'orientaci a objectes durant les tasques d'anlisi es va popularitzar, especialment, a partir de l'aparici el 1997 del llenguatge unificat de modelitzaci (UML) creat per James Rumbaugh, Grady Booch i Ivar Jacobson.
Comunicaci amb UML

 FUOC PID_00171145

10

Orientaci a objectes

2. Classificaci i abstracci

Un sistema orientat a objectes est format per una srie d'elements autnoms (els objectes) que es comuniquen els uns amb els altres per tal de dur a terme les seves tasques.

Per tant, el primer que hem de saber en un sistema com aquest s qu pot fer cadascun d'aquests objectes: quines coses sap, amb quins altres objectes es pot comunicar o quines tasques se li poden demanar.

Anomenarem responsabilitats de l'objecte aquestes caracterstiques.

2.1. Classificaci Quan descrivim un determinat sistema fent servir orientaci a objectes descriurem els objectes que formen aquest sistema. Si intentem descriure un per un aquests objectes, per, aviat trobem que hi ha objectes que sn d'un mateix tipus i tenen una mateixa estructura i responsabilitats.
Exemple de classificaci Si estem descrivint una empresa, per exemple, segurament tindrem algun objecte que representa un treballador concret. Aquest treballador pot tenir responsabilitats com "saber quin s el seu nom", "saber quin s el seu departament" o "calcular quants companys t (s a dir, quants treballadors pertanyen al mateix departament que ell)". Per de seguida veiem que hi ha molts altres objectes a la mateixa empresa que tamb representen treballadors i que, per tant, tamb tenen les responsabilitats de "saber quin s el seu nom", "saber quin s el seu departament" i "calcular quants companys t".

A l'hora de fer la descripci del nostre sistema, per tant, no ens interessar tant l'objecte en si (en aquest cas, una persona, l'individu) com la classe d'objectes que tenen les mateixes responsabilitats (en aquest cas, els treballadors).

La classificaci s el mecanisme mitjanant el qual simplifiquem la descripci dels objectes del sistema i identifiquem aquelles classes d'objectes tals que tots els objectes de la mateixa classe tenen les mateixes responsabilitats.

En el cas anterior, tots els treballadors saben quin s el seu nom (encara que cada treballador tingui un nom diferent, cadasc sap quin s el seu), saben quin s el seu departament i poden calcular quants companys tenen.

 FUOC PID_00171145

11

Orientaci a objectes

Classificaci dels objectes

Anomenem classe el grup i instncia l'objecte.

Classes d'objectes A l'exemple anterior tenim tres classes d'objectes: Crrecs, Empleats i Departaments.

De la classe Crrec en tenim tres instncies (Director, Ajudant i Responsable), d'Empleat, vuit, i de Departament, tres (Vendes, Finances i Informtica).

A l'hora de definir les responsabilitats dels objectes d'una classe, les podem dividir en tres tipus: 1) La informaci que coneixen (les dades) 2) Els objectes que coneixen (les associacions) 3) Les tasques que poden dur a terme (les operacions)
A l'exemple anterior, cada instncia d'Empleat sap quina s la informaci de l'empleat (el nom, el telfon, etc.), est associada amb altres instncies (el seu crrec i el seu departament) i hi ha una srie de tasques que pot dur a terme (redactar una sollicitud, aprovar-la, etc.). Instncies

 FUOC PID_00171145

12

Orientaci a objectes

2.2. Abstracci

En orientaci a objectes, l'abstracci s el mecanisme mitjanant el qual decidim quines de les possibles responsabilitats associades a una classe formaran part de la seva definici.

A l'hora de descriure un sistema mitjanant l'orientaci a objectes, haurem d'aplicar el mecanisme d'abstracci als tres tipus de responsabilitat que hem vist anteriorment per a decidir quines dades, relacions i comportament sn rellevants per al nostre problema.
En el cas de l'exemple anterior, s ben probable que trets com el color dels ulls, l'alada o qui s amic de qui entre els treballadors o el fet que a alguns treballadors els poguem demanar que facin la declaraci de renda no siguin rellevants i, per tant, no es tinguin en compte.

2.3. Descripci de les classes d'objectes Aplicant la classificaci i l'abstracci arribarem a una primera descripci dels objectes que formen part del nostre sistema, en qu tindrem un conjunt de classes i, per a cada classe, un conjunt de responsabilitats. Aquestes responsabilitats prendran la forma d'atributs, operacions i associacions. 2.3.1. Atributs Quan tots els objectes d'una classe tenen un mateix element d'informaci (com ara la data de contractaci a l'empresa), encara que cada objecte hi tingui un valor diferent, diem que la classe t un atribut.

Els atributs ens diuen quina informaci (quines dades) coneixem sobre els objectes d'una classe determinada.

L'atribut tindr un nom que ens permet distingir-lo de la resta d'atributs (per exemple, podem anomenar Alta l'atribut que desa la data en qu un empleat va ser donat d'alta a l'empresa) i sol tenir un tipus que ens ajuda a entendre millor el tipus d'informaci que s'hi emmagatzema i a saber quins valors sn vlids per a l'atribut (per exemple, si diem que Alta s de tipus Data, sabem que els valors que pot prendre han de ser dates i no pas nombres enters).

String Anomenem String el tipus d'atributs en que els valors sn seqncies de carcters; s a dir, textos sense cap format. Formalment, un String s una seqncia de smbols que s'escullen d'un conjunt o d'un alfabet.

 FUOC PID_00171145

13

Orientaci a objectes

Exemple de classe amb atributs i de dues de les seves instncies

mbit de l'atribut Els atributs poden emmagatzemar, o b un valor diferent per a cada instncia, o b un mateix valor per a totes les instncies de la classe. Per exemple, l'atribut Alta que emmagatzema la data en qu es va incorporar el treballador a l'empresa ha de tenir un valor diferent per a cada treballador. En aquest cas, diem que l'atribut t mbitd'instncia. En canvi, un atribut anomenat mitjanaEdats que emmagatzems la mitjana de les edats de tots els treballadors no tindria sentit que dons valors diferents per a diferents instncies ja que, sigui quin sigui el treballador a qui preguntem, la mitjana de les edats ha de ser la mateixa; en aquest cas, diem que l'atribut t mbitdeclasse. Aquests atributs (amb mbit de classe), per, sn poc habituals. Nombre de valors d'un atribut Fins ara hem vist atributs tals que cada instncia noms pot tenir un valor, i l'ha de tenir per fora. Diem que sn atributs univaluats i obligatoris. Per alguns atributs poden no tenir valor en algunes instncies (atributs opcionals) o en poden tenir ms d'un (atributs multivaluats).
Exemples d'atributs opcionals i multivaluats El nmero de fax d'un treballador podria ser un atribut opcional (ja que un treballador podria no tenir nmero de fax); d'altra banda, el nmero de telfon podria ser multivaluat, ja que podria ser que un treballador tingus ms d'un nmero de telfon en el qual es pogus localitzar.

2.3.2. Associacions Les associacions ens diuen quins altres objectes coneixen els objectes d'una classe (quines sn les seves relacions amb altres objectes). Per tant, formen part del conjunt d'informaci (les dades) que gestiona un objecte i, com a tals, les podrem considerar atributs. A diferncia dels atributs que hem considerat fins ara, per, una associaci no fa referncia a un nic objecte sin que sempre far referncia, com a mnim, a dos objectes. Per aix distingim entre atributs i associacions.

 FUOC PID_00171145

14

Orientaci a objectes

Per exemple, hem dit que ens interessa saber, per a una instncia concreta de departament, quins empleats hi pertanyen. En aquest cas direm que hi ha una associaci entre les classes Empleat i Departament. L'associaci pot tenir un nom (per exemple, podem anomenar treballaA la relaci entre un empleat i el seu departament). A diferncia d'un atribut, l'associaci treballaA sempre fa referncia a dos objectes: un empleat i un departament.

Una associaci entre dues classes indica que les instncies de cada classe saben, com a part de les seves responsabilitats, amb quina o quines instncies de l'altra classe estan relacionades.

La relaci d'associaci entre dues instncies s recproca, de tal manera que si una instncia a d'una classe A est associada amb una instncia b de la classe B, la instncia b estar tamb associada a la instncia a. Quan una classe est associada amb una altra, podem consultar el vincle entre les instncies relacionades. Aix, si diem que la classe Empleat est associada a la classe Departament, estem dient que, donada una instncia concreta de la classe Empleat, li podrem demanar amb quines instncies de la classe Departament est associada o, si ho volem fer a la inversa, donada una instncia concreta de Departament, li podrem demanar amb quines instncies d'Empleat est associada.
Exemple d'associacions A l'exemple de la figura segent, podem saber que l'empleada Laura Mart t associat el Departament de Vendes, l'empleada Rosa Sils, tamb, i que el Departament de Vendes t associats els empleats Laura Mart i Rosa Sils. Associaci Empleat-Departament(treballaA)

Tot i que l'associaci s una caracterstica de la classe, els valors que pren seran especfics de les instncies (igual que passa amb els atributs). Per, a diferncia dels atributs, les associacions mai no tindran mbit de classe.

 FUOC PID_00171145

15

Orientaci a objectes

Rols de les instncies Quan una instncia participa en una associaci amb altres instncies, sempre ho ha de fer tenint un rol concret. De vegades, aquest rol tindr un nom explcit i, fins i tot, podr tenir una visibilitat (pblic, privat, etc.). El rol s especialment important en el cas de les associacionsrecursives, que sn aquelles associacions que connecten una classe amb ella mateixa.
Exemple d'associaci recursiva Si tenim la classe Persona i volem definir la relaci entre pares i fills, tindrem una associaci recursiva a la classe Persona, ja que estem connectant la classe Persona amb ella mateixa. En aquest cas, una instncia de persona pot tenir el rol de pare o de fill en relaci a una altra instncia. s important veure, per, que una mateixa instncia de Persona pot tenir el rol de pare en relaci a una instncia i, al mateix temps, tenir el rol de fill en relaci a una altra. Associaci recursiva

El rol tamb s important quan tenim ms d'una associaci entre dues classes.
Per exemple, la classe Persona i la classe Ciutat podrien tenir dues associacions: la que ens diu on va nixer una persona (ciutat natal) i la que ens diu on viu la persona (ciutat de residncia). En aquest cas no n'hi ha prou de dir que una ciutat est associada a una persona sin que cal distingir quin dels dos rols t la ciutat en la seva associaci amb la persona (s a dir, si s la seva ciutat natal o si s la seva ciutat de residncia). A priori, res no impedeix que una mateixa ciutat tingui els dos rols per, tot i aix, considerarem que la ciutat est associada dues vegades a la persona, una com a ciutat natal i una altra com a ciutat de residncia.

Classes associatives
Nota d'un estudiant Suposem el cas segent. Un estudiant est matriculat d'una assignatura i, en finalitzar el curs, li queda una nota de B. De quina classe s atribut la nota que l'estudiant treu d'una assignatura? Si fem que la nota sigui un atribut d'estudiant llavors no dependria de l'assignatura; direm, per exemple, que en Joan (un estudiant) t una nota de B... per, de quina assignatura? Si, en canvi, definim la nota com un atribut d'assignatura, llavors no dependria de l'estudiant. En realitat, la nota pertany a l'associaci entre l'estudiant i l'assignatura.

Una classeassociativa s aquella classe les instncies de la qual sn instncies d'una associaci. A l'exemple anterior, tindrem una classe associativa anomenada Matrcula les instncies de la qual serien les parelles (Estudiant, Assignatura) que estan relacionades.

 FUOC PID_00171145

16

Orientaci a objectes

Una instnciad'unaassociaci s una parella d'instncies de les classes que l'associaci relaciona. Podem parlar d'instncies d'associaci tant si l'associaci s una classe associativa com si no ho s. En el primer cas, per, aquestes instncies sn, alhora, objectes d'una classe i, per tant, poden tenir, al seu torn, atributs, operacions, mtodes i associacions.

Classe associativa

Associacions n-ries Fins ara, totes les associacions que hem vist eren entre dues classes per, de vegades, es pot donar el cas de tenir associacions entre tres o ms classes.
Exemple d'associaci n-ria La matrcula d'un estudiant la podem veure com una associaci binaria (Estudiant, Assignatura) o b com una associaci ternria (Estudiant, Semestre, Assignatura). En el segon cas, no hi ha una nica associaci entre l'estudiant i l'assignatura sin diverses, cadascuna corresponent a un semestre diferent. En el cas de tenir una classe associativa, les instncies de la classe sempre estaran relacionades amb una instncia de cadascuna de les classes de l'associaci. Aix doncs, no t sentit parlar de la nota de l'estudiant en aquella assignatura sin de la nota de l'estudiant en aquella assignatura i en aquell semestre.

2.3.3. Operacions

Les operacions ens diuen quines tasques poden dur a terme les instncies d'una classe (quin s el seu comportament observable).

A l'hora de definir el comportament d'un objecte distingim entre l'operaci (la definici de qu pot fer) i el mtode (el conjunt d'instruccions que indica com ho ha de fer). Les operacions formen part de la interfcie, mentre que els mtodes formen part de la implementaci.

Vegeu tamb Podeu trobar ms informaci sobre la diferncia entre interfcie i implementaci al mdul "Introducci a l'enginyeria del programari".

 FUOC PID_00171145

17

Orientaci a objectes

Quan un objecte vol que un altre executi el comportament definit en una de les seves operacions, diem que invoca (o crida) aquella operaci o b que li envia aquell missatge.
Per exemple, si la classe Treballador t una operaci anomenada quantsCompanys, diem que s'invoca o es crida l'operaci quantsCompanys o b que se li envia el missatge quantsCompanys. Exemple de classe amb atributs i operacions i de dues de les seves instncies

Operacions, mbit de classe o d'instncia Les operacions tamb poden tenir mbit de classe (el missatge el rep la classe) o d'instncia (el missatge el rep una instncia en concret) tot i que, de moment, no cal que ho tinguem en compte.

 FUOC PID_00171145

18

Orientaci a objectes

3. Ocultaci d'informaci i encapsulament

Hem vist que, grcies a la classificaci i l'abstracci, podem simplificar la descripci dels objectes agrupant-los en classes i centrant-nos noms en aquelles responsabilitats que siguin rellevants per al nostre cas. Tamb hem vist que ens interessa "ocultar informaci" per tal de separar la interfcie d'un objecte de la seva implementaci i poder oferir a la resta d'objectes del sistema una versi encara ms simplificada d'aquest.
Vegeu tamb Hem vist al mdul "Introducci a l'enginyeria del programari" que ens interessa separar la interfcie d'un objecte de la seva implementaci.

L'encapsulament s el mecanisme de l'orientaci a objectes que ens permet ocultarinformaci.

3.1. Ocultaci d'informaci El concepte d'ocultaci d'informaci s molt anterior als llenguatges orientats a objectes. De fet, va ser mencionat per primer cop per David Parnas (1972).

Ocultaci d'informaci segons David Parnas Cada element (mdul o subsistema) del sistema cont una certa informaci que "oculta" a la resta de mduls presentant-los una visi simplificada.

Una descripci en qu no expliquem el funcionament intern de l'objecte descrit es coneix com a descripci de "caixa negra".
Exemple de descripci de "caixa negra" Suposem que volem descriure a una altra persona com funciona una aixeta de palanca. Segurament la nostra descripci seria de l'estil de: "L'aixeta t una palanca que, quan la puges, fa que surti aigua (com ms la puges ms aigua surt) i quan la baixes tanca l'aixeta. Per a regular la temperatura has de moure la palanca a l'esquerra (si vols l'aigua ms calenta) o a la dreta (si la vols ms freda)".

 FUOC PID_00171145

19

Orientaci a objectes

Aixeta vista com a caixa negra

Amb aquesta descripci, per, noms hem descrit com es fa servir l'aixeta, no pas com funciona per dintre. Si fos un lampista qui li demana a un altre lampista com funciona una aixeta de palanca segurament ens diria alguna cosa similar al segent: "L'aixeta t dues entrades d'aigua, una de freda i una de calenta. La palanca va connectada a una rtula que regula el pas d'aigua de les dues entrades: a la posici central deixa passar aigua de tots dos circuits, mentre que si movem la palanca, anirem ampliant el pas d'un circuit al mateix temps que tanquem el pas de l'altre." Aixeta vista com a caixa blanca

Les descripcions que inclouen els detalls de funcionament les coneixem com a descripcions de "caixa blanca". Totes dues sn descripcions vlides de l'aixeta de palanca, per mentre que la primera s molt fcil d'entendre, la segona requereix una mica ms d'esfor i de coneixements sobre lampisteria. Aplicant el principi d'ocultaci d'informaci, la primera descripci omet el detall sobre com es regulen els dos circuits d'aigua i es limita a explicar-nos que, movent la palanca, alterem la temperatura de l'aigua. De la mateixa manera, en descriure les responsabilitats d'una classe, ho podem fer des d'un punt de vista extern (com una "caixa negra"), indicant noms com es poden fer servir els objectes d'aquella classe, o b des d'un punt de vista intern (o de "caixa blanca"), indicant com est estructurat l'objecte i com funciona per dintre.

 FUOC PID_00171145

20

Orientaci a objectes

3.2. Encapsulament

L'encapsulament ens permet ocultar informaci a altres objectes i definir quins atributs, operacions i associacions d'un objecte els seran visibles i quins estaran ocults.

D'aquesta manera els atributs i operacions que no hem fet visibles queden ocults a la resta d'objectes que, per tant, no necessiten (de fet no poden) saber de la seva existncia. El fet que les dades i les operacions formin part de la mateixa entitat (l'objecte) facilita encara ms l'ocultaci d'informaci.

S'anomena visibilitat d'un atribut, associaci o operaci, la propietat que defineix quins objectes el poden veure.

La visibilitat, doncs, determina quins objectes poden consultar el valor de l'atribut o de l'associaci o b invocar l'operaci. En general, diem que la visibilitat determina quins objectes tenen accs a una responsabilitat determinada. Els diferents llenguatges de programaci defineixen diferents tipus de visibilitat, per els casos ms tpics sn: Visibilitat pblica: qualsevol objecte hi t accs. Visibilitat privada: noms els objectes de la mateixa classe hi tenen accs. Visibilitat protegida: noms els objectes de la mateixa classe o d'alguna subclasse hi tenen accs. Visibilitat de paquet: noms els objectes del mateix grup o "paquet" hi tenen accs.
Paquet Un paquet s una agrupaci d'elements en un sistema orientat a objectes per a facilitar-ne l'organitzaci. Un paquet pot contenir classes i altres paquets i pot resultar til per a definir la visibilitat de paquet dels atributs, associacions i operacions de les classes que cont.

Vegeu tamb Veurem el concepte de subclasse en l'apartat 4 d'aquest mdul.

Com a efecte collateral, l'ocultaci d'informaci t l'avantatge que alg podria crear una implementaci alternativa (per exemple, fabricar una aixeta de palanca que substitus la rtula per algun altre mecanisme) sense que aix afects els usuaris de la classe, ja que el comportament observable (la interfcie) seria el mateix.
Exemple d'encapsulament A la figura segent tenim dues possibles implementacions per a una mateixa interfcie. En tots dos casos, els atributs pblics sn els mateixos (Nom, Telfon, Antiguitat) per es calcularien de manera diferent a partir de conjunts d'atributs privats diferents.

 FUOC PID_00171145

21

Orientaci a objectes

Encapsulament

 FUOC PID_00171145

22

Orientaci a objectes

4. Herncia i polimorfisme

4.1. Herncia Fins ara noms hem tingut en compte un nivell de classificaci (un objecte pertany a una classe) per, de la mateixa manera que la classificaci ens permet simplificar la descripci que fem d'un objecte agrupant els objectes en classes, de vegades podem simplificar la descripci d'una classe identificant responsabilitats comunes entre les instncies de diferents classes.
Classificaci dels ssers vius Podem considerar el cas de la classificaci dels ssers vius. Una abella qualsevol podria ser un exemplar d'abella europea (Apis mellifera). Per a l'hora de descriure com s l'abella, sabem que t caracterstiques comunes amb altres ssers vius que no sn abelles (els altres insectes) que, al seu temps, comparteixen caracterstiques amb altres ssers vius que no sn necessriament insectes (com els artrpodes), que al seu temps comparteixen caracterstiques amb la resta d'animals. Classificaci de l'abella europea

Aquest tipus de classificaci jerrquica el podem reproduir en un sistema orientat a objectes mitjanant el mecanisme d'herncia entre classes.

Diem que una classe (subclasse) hereta la definici d'una altra classe (superclasse) quan volem reutilitzar la definici de la superclasse de manera que aquesta s'apliqui tamb a les instncies de la subclasse. Aquest mecanisme ens permet, a l'hora de definir una subclasse, indicar noms aquelles caracterstiques que en sn especfiques, mentre que les que sn comunes amb altres subclasses de la mateixa superclasse, diem que les hereta.
Tornant a l'exemple de les abelles, quan estem definint la classe abella, no cal que indiquem que t tres parells de potes sin que en tenim prou de dir que s una subclasse d'insecte (i, per tant, la classe abella hereta aquesta caracterstica). Si modifiquem la definici de la classe insecte i afegim que t dues antenes, automticament totes les subclasses d'insecte (entre elles, abella) passen a heretar aquesta nova caracterstica.

 FUOC PID_00171145

23

Orientaci a objectes

Relacions is-a i is-like-a La relaci d'herncia es coneix tamb com a relaci is-a (s-un), ja que les instncies de la subclasse sn tamb de la superclasse (una abella is-a un insecte). De vegades, per, ens pot interessar que la subclasse afegeixi caracterstiques que no sn aplicables a la superclasse (per exemple, una bomba de calor s com un aparell d'aire condicionat per que en comptes de noms refredar tamb pot donar calor). En aquests casos, la relaci seria is-like-a (s-com-un) i hi ha certa controvrsia sobre si aquest s o no un s correcte de l'herncia.

La relaci d'herncia no s'ha de limitar necessriament a un sol nivell ni a dues subclasses noms, sin que podem arribar a tenir classificacions arbitrriament complexes. 4.1.1. Generalitzaci i especialitzaci Hi ha dos processos que ens permeten identificar fcilment les relacions d'herncia al nostre domini: la generalitzaci i l'especialitzaci. El procs de generalitzaci consisteix a trobar classes ms generals a partir de les que ja tenim, mentre que l'especialitzaci consisteix a trobar classes ms especfiques a partir de les que ja tenim. La generalitzaci s un procs que es du a terme en dues etapes: el primer pas s identificar responsabilitats comunes a dues o ms classes.
Exemple de primera etapa de la generalitzaci A la universitat tenim instncies d'Estudiant, de les quals sabem que tenen un nom, uns cognoms, una edat i que estan matriculats d'un nombre concret de crdits. Tamb tenim instncies de Professor, de les quals sabem que tenen un nom, uns cognoms, una edat i una antiguitat a la universitat. Podem veure, doncs, que els estudiants i els professors, si b no sn la mateixa classe (per exemple, cap professor no est matriculat de crdits ni sabem l'antiguitat de cap estudiant), s que comparteixen algunes caracterstiques (nom, cognoms i edat).

El segon pas de la generalitzaci consisteix a crear una nova classe i crear una relaci d'herncia entre les classes que tenem i la classe que hem afegit.
Al nostre exemple, afegirem una classe Persona i farem que, tant Estudiant com Professor, fossin subclasses de Persona.

L'especialitzaci s el procs simtric a l'anterior: primer identifiquem un subconjunt de les instncies d'una classe que comparteixen alguna caracterstica comuna (per exemple, hi ha un subconjunt de persones que es poden matricular d'assignatures, mentre que la resta no ho poden fer) i desprs creem una subclasse nova que inclou aquest conjunt d'instncies i afegeix a la seva definici la caracterstica que els s especfica.
Si estudissim el ADN de les abelles europees, veurem que no sn totes iguals, sin que hi ha diversos grups, com ara el grup afric, el mediterrani o el de l'Orient Mitj. En aquest cas, a partir de la classe abella europea, anirem creant subclasses per especialitzaci a mesura que anssim descobrint els diferents grups.

 FUOC PID_00171145

24

Orientaci a objectes

4.2. Polimorfisme En el cas de les abelles, un mateix espcimen el podem veure com una abella (per exemple, si no hi entenem gaire) o com una abella europea del grup afric (si, per exemple, estigussim interessats a estudiar la distribuci geogrfica dels diferents grups). Aix s molt til perqu ens permet treballar a diferents nivells d'abstracci segons quin sigui el nostre inters en els detalls.

El polimorfisme s la capacitat d'un objecte de presentar-se amb formes diferents (interfcies diferents) segons el context.

A l'exemple anterior, l'espcimen es presenta amb forma (o interfcie) d'abella per a l'observador no expert mentre que, per a l'observador expert, es presenta en forma d'abella europea del grup afric. Polimorfisme

s important veure, per, que l'espcimen (l'individu, la instncia) s el mateix en tots dos casos i que, per tant, el polimorfisme est relacionat amb la visi que els altres objectes tenen de l'objecte ms que no pas amb l'objecte en si, que sempre pertany a la classe ms concreta de la jerarquia, encara que alguns observadors no ho vegin.
A l'exemple anterior, encara que l'observador no expert noms vegi una abella, l'abella que est veient sempre s una abella europea del grup afric. Exemple de polimorfisme Si volem saber el nom d'una persona que participa al campus virtual de la UOC, ens s igual saber si s un consultor o un estudiant i, per tant, farem servir la interfcie de persona independentment del tipus concret de persona que sigui. En canvi, si volem saber si la persona est matriculada d'una assignatura, hem de tenir en compte el tipus de persona que s, ja que els consultors no es matriculen i, per tant, la pregunta noms t sentit per als estudiants (i hem de fer servir la interfcie d'estudiant).

El polimorfisme afecta tant les dades com el comportament, i permet que les subclasses redefineixin algunes operacions per tal de comportar-se de manera diferent de la resta d'instncies (s el que anomenem operacions polimrfiques).

 FUOC PID_00171145

25

Orientaci a objectes

Una operacipolimrfica s una operaci que t un comportament diferent en funci de la classe concreta a la qual pertanyi un objecte.

Per exemple, hi ha grups d'abelles que sn ms agressius que altres i que, per tant, respondran de manera diferent al mateix estmul. En aquest cas, podem dir que la classe abella defineix l'operaci molestar amb el comportament fugir per que hi ha una subclasse que la redefineix amb el comportament atacar; diem que l'operaci molestar s polimrfica perqu si molestem una abella el seu comportament ser diferent segons el tipus concret d'abella que sigui (podria fugir si s una de les normals o atacar-nos si s una de les agressives).

4.2.1. Classes abstractes i redefinici del comportament En una classificaci jerrquica com les que estem proposant, podria passar que una superclasse no tingus cap instncia que no pertanys a una subclasse (per exemple, la classe abella no t cap instncia que no sigui d'alguna subclasse com ara l'abella europea).

Anomenem classes abstractes les classes que no es poden instanciar directament; aquestes classes s'han d'instanciar per mitj de les seves subclasses.

A l'exemple anterior, si volem una instncia d'abella, hem de decidir de quin subtipus d'abella ha de ser. Les classes abstractes poden definir tant dades com comportament que heretaran les seves subclasses. Una caracterstica, per, especfica de les classes abstractes, s que poden definir operacionsabstractes.

Una operaciabstracta s una operaci que no t associat un mtode (s a dir, no s'ha definit un comportament) en la classe en qu es defineix.

Aix obliga les subclasses a definir un mtode (comportament) per a aquella operaci o a ser igualment abstractes i deixar que siguin les seves subclasses les que defineixin el comportament.
Exemple d'operaci abstracta Si tornem a l'exemple de les aixetes, podem considerar que tenim una classe abstracta Aixeta i dues subclasses, Aixeta de palanca i Aixeta termosttica. En aquest cas, la classe Aixeta pot oferir una operaci anomenada tancar, que tancar l'aixeta i far que en deixi de brollar aigua. El comportament d'aquesta operaci, per, ser diferent en funci del tipus concret d'aixeta. En aquest exemple, l'operaci tancar de la classe Aixeta s abstracta perqu no defineix cap implementaci definida i les subclasses Aixeta de palanca i Aixeta termosttica la implementen de manera diferent (cadascuna definint el seu comportament propi).

 FUOC PID_00171145

26

Orientaci a objectes

4.2.2. Associacions polimrfiques Les associacions ens permeten donar una nova utilitat al polimorfisme: podem tenir associacions amb una superclasse de manera que no ens hem de preocupar de la subclasse concreta dels objectes que tenim associats.
Exemple d'associaci polimrfica Un aula del campus virtual pot tenir una llista de persones participants, per a les quals no necessita saber si sn estudiants o professors, sin noms saber si sn persones, si participen a l'aula i quin s el seu nom. Associaci polimrfica

Aquest s del polimorfisme, a ms, ens ajudar a evolucionar el sistema si, en un futur, descobrim altres tipus de persones (sempre que aquestes tamb tinguin nom i puguin rebre missatges).

 FUOC PID_00171145

27

Orientaci a objectes

5. Cas prctic: un frum virtual

A continuaci aplicarem els principis i les tcniques vistos anteriorment a un domini molt petit per prou representatiu: un sistema de frums virtuals en qu els usuaris envien missatges a un frum i poden llegir els missatges que han enviat els altres usuaris. s molt important, per, abans d'aplicar el qu hem vist, que considerem quina s la finalitat de la tasca que estem duent a terme. Com hem dit amb anterioritat, el paradigma de l'orientaci a objectes es pot aplicar en mbits diferents, com ara la descripci del domini durant l'anlisi o b la implementaci del programari del sistema. En aquest exemple ens centrarem en l's de l'orientaci a objectes com a tcnica per a la descripci del domini del problema i, per tant, el nostre objectiu s identificar les classes del domini i no pas les classes de programari que formaran part de la soluci. Per tant, veurem classes com Missatge o Frum per no pas BaseDeDadesDeMissatges. 5.1. Classificaci dels objectes Comenarem identificant les classes i els atributs dels objectes. En aquest primer pas crearem les abstraccions bsiques del nostre sistema i descartarem tots els detalls que no considerem rellevants. 5.1.1. Classes En aquest cas, fent un exercici d'abstracci, podem identificar fcilment tres classes ben diferenciades: Usuari, Missatge i Frum. Usuaris sn aquelles persones que fan servir el sistema, missatges sn el que s'envien els usuaris, i els frums serveixen per a agrupar els missatges. Tots els objectes que tinguem al domini pertanyeran a alguna d'aquestes tres classes i, per tant, no considerarem cap classe ms si no s que incorporem ms informaci que la que tenim actualment.
Classes Observaci El model del domini que fem durant l'anlisi fa servir els objectes per a representar conceptes del mn real i, per tant, no ens interessa identificar-hi operacions ni assignar-los mtodes, ja que aquestes tasques es faran durant el disseny i implementaci del sistema.

 FUOC PID_00171145

28

Orientaci a objectes

5.1.2. Atributs Per a determinar els atributs de les diferents classes, hem de determinar quins detalls sn rellevants per al nostre sistema de les instncies de cada classe. Dels usuaris podrem conixer molta informaci (el nom, l'edat, les seves aficions, el color dels ulls, on treballen, si els agrada l'pera, etc.), per molta d'aquesta informaci no s rellevant per al sistema que estem desenvolupant i, per tant, no l'hem de considerar com a atributs de la classe. En canvi, segur que necessitarem una manera d'identificar els usuaris (per exemple, fent servir un nom que podria ser el seu nom real o un lies) per tal de poder saber qui ha creat un missatge i, de la mateixa manera, necessitarem poder determinar que un usuari s qui diu ser (per exemple, mitjanant un mot de pas); en aquest cas, doncs, direm que la classe Usuari t dos atributs: nomUsuari (el que fa servir per a autenticar-se al sistema) i motDePas (la contrasenya). Altres detalls de l'usuari, com ara el nom, els cognoms i l'edat, podrien ser atributs o no segons els considerem rellevants per al sistema que estem descrivint. Per simplificar l'exemple, els considerarem no rellevants i, per tant, no els convertirem en atributs. Dels missatges tamb en podrem saber tot de coses com ara la longitud del contingut, si s interessant o s avorrit, etc., per ens quedarem amb dos atributs que considerem rellevants: ttol i contingut. Finalment, dels frums ens interessar saber-ne el nom (per poder-los distingir dels altres). Per tant, tenim les classes i atributs segents:
Classes i atributs

5.2. Herncia En aquest cas no s possible generalitzar cap de les classes identificades, ja que representen conceptes molt diferents entre si. En canvi, podria passar que una anlisi ms a fons de la funcionalitat ens ports a pensar que alguns dels usuaris tenen permisos especials i poden esborrar els missatges d'altres usuaris.

 FUOC PID_00171145

29

Orientaci a objectes

Com que no tots els usuaris tenen aquest perms especial, podrem identificar un subconjunt d'Usuaris que anomenarem Moderadors, que sn aquells que poden esborrar missatges d'altres usuaris. En aquest cas, doncs, haurem afegit una classe nova per especialitzaci:
Especialitzaci de Moderador

5.3. Associacions Pel qu fa a les associacions, podrem identificar una associaci entre Usuari i Missatge, en qu Usuari t el rol d'autor i Missatge el de missatge, i on desarem quin usuari s l'autor d'un missatge. Tamb necessitarem saber a quin frum pertany un missatge (anomenarem pertany aquesta associaci i missatge i frum, els rols del missatge i del frum, respectivament). Alguns missatges poden ser respostes a missatges anteriors. Aquesta associaci s una associaci recursiva, ja que associa dues instncies de la mateixa classe (Missatge): una t el rol de missatge original i l'altra t el rol de resposta. Finalment, tamb ens interessar saber qui s el moderador d'un frum en concret. En aquest cas, en comptes d'associar Frum i Usuari associarem Frum i Moderador, ja que sabem que noms el subconjunt d'usuaris que sn moderadors estan capacitats per a moderar un frum.

 FUOC PID_00171145

30

Orientaci a objectes

Associacions

 FUOC PID_00171145

31

Orientaci a objectes

Resum

Hem vist com una eina que es va crear com a mecanisme d'abstracci per als llenguatges de programaci ens permet simplificar la descripci de qualsevol sistema del mn real. Per tant, hem de veure l'orientaci a objectes no solament com un paradigma de programaci, sin com un paradigma d'anlisi que podem aplicar al mn real. L'orientaci a objectes ens proporciona una manera d'abstraure les caracterstiques importants de les entitats que formen el nostre domini, classificar-les de manera que en puguem maximitzar la reutilitzaci i que puguem variar el nivell d'abstracci al qual treballem i, al mateix temps, establir relacions entre aquestes mitjanant associacions. Hem vist com podem classificar els objectes en classes i fer abstracci dels aspectes rellevants a l'hora de descriure les classes mitjanant les diferents responsabilitats que es traduiran en atributs, associacions i operacions. Tamb hem vist com l'encapsulament ens permet establir la visibilitat de cadascuna de les responsabilitats i ocultar, aix, els detalls d'implementaci a la resta de classes. Finalment, l'herncia ens permet establir jerarquies de classe de tal manera que puguem descriure els trets comuns a diverses classes en una classe ms general, mentre que el polimorfisme ens permet veure un mateix objecte com d'una o altra classe de la jerarquia en funci del context. Un model orientat a objectes del nostre domini ens facilitar, ms endavant, la creaci de classes de programari que reflecteixin aquest domini, al mateix temps que ens pot ajudar a la creaci d'altres models (com ara l'estructura de la base de dades) mantenint, al mateix temps, la possibilitat de fer-lo servir per a comunicar-nos amb les persones expertes en el domini sense necessitat que siguin expertes en programaci orientada a objectes.

 FUOC PID_00171145

33

Orientaci a objectes

Activitats
1. A l'exemple del subapartat 2.3.1 hem dit que el telfon s un atribut de tipus String. Per qu no l'hem indicat com de tipus numric? 2. Estem fent l'anlisi orientada a objectes per a un sistema de comer electrnic. L'empresa vendr una srie de productes dels quals tindrem un nom, la marca comercial, una descripci, una fotografia i el preu. Alguns productes sn electrnics, en el sentit que sn documents binaris que es poden descarregar i no objectes fsics que cal enviar; per a aquests, tamb volem tenir-ne el fitxer i el format, que pot ser msica, llibre o pellcula. Cada producte podr pertnyer a una o ms categories, cadascuna de les quals tindr un nom i una descripci. Els usuaris tindran un nom d'usuari, una contrasenya i una adrea i faran compres de les quals desarem la data i el conjunt de productes comprats. D'un mateix producte, en una compra, se'n podran comprar una o ms unitats. No tindrem en compte el pagament.

Feu una llista de les classes que podem trobar en aquest domini. Per a cada classe, indiqueu els atributs que t, el tipus de cada atribut i quin s el seu nombre possible de valors. Identifiqueu les associacions entre classes. Per a cada una indiqueu els noms dels rols i, si n'hi ha, els atributs que tingui la classe associativa. Identifiqueu les relacions d'herncia entre classes i quines classes creieu que sn abstractes.

3. Tenim un sistema orientat a objectes amb les classes Vehicle, Cotxe, Moto i Conductor. La classe Vehicle, que s abstracta, t l'atribut pblic matrcula, l'atribut protegit marca i l'atribut privat model. Cotxe i Moto sn subclasses de la classe Vehicle. a) Quins atributs de Vehicle sn visibles des de la classe Vehicle? b) I des de la classe Cotxe? c) I des de Persona? 4. Tenim un sistema orientat a objectes amb les classes Be, BeImmoble (que s subclasse de Be) i Contribuent. Entre Contribuent i Be hi ha una associaci, de tal manera que un contribuent t qualsevol nombre de bns, cadascun dels quals pertany a un o ms contribuents. Be t l'atribut valor, mentre que BeImmoble t un atribut referenciaCatastral. Be t una operaci calcularImpostos que calcula d'impost per aplicar als contribuents que tenen el b associat. BeImmoble redefineix l'operaci calcularImpostos i, a ms, t una operaci prpia anomenada hipotecar, amb diversos parmetres. a) Pot passar que un contribuent tingui associat un b immoble? b) Un contribuent podria demanar l'operaci hipotecar sobre tots els seus bns associats? c) Segons aquest esquema, els bns immobles tenen valor? d) Els bns tenen referncia catastral? 5. Suposeu que tenim el mateix sistema orientat a objectes de l'exercici anterior. Ara, per, sabem que l'atribut valor de la classe Be s privat. I ara, els bns immobles tenen valor? Des de la classe BeImmoble es pot accedir a l'atribut valor?

Exercicis d'autoavaluaci
1. Quina s la diferncia fonamental entre els llenguatges de programaci procedimentals i els orientats a objectes pel que fa a l'abstracci? 2. Quina relaci hi ha entre l'anlisi orientada a objectes i la programaci orientada a objectes? 3. En orientaci a objectes, amb quin criteri agrupa objectes el mecanisme de classificaci? 4. Quins tipus de responsabilitats poden tenir els objectes? 5. Quin mecanisme de l'orientaci a objectes ens permet descartar trets caracterstics dels objectes que no siguin rellevants al problema que volem resoldre?

 FUOC PID_00171145

34

Orientaci a objectes

6. Quin element de la classe ens indica la informaci que coneixem de les seves instncies? 7. Quina informaci coneixem dels atributs d'una classe, a ms del nom? 8. Qu vol dir que la relaci d'associaci sigui recproca? 9. Pot existir una associaci d'una classe amb si mateixa? En tal cas, com distingim una instncia d'una altra entre dues que estan relacionades? 10. En orientaci a objectes, com modelitzem les tasques que poden portar a terme els objectes? 11. Quina relaci hi ha entre operacions, mtodes, interfcie i implementaci? 12. Quina altra metfora es fa servir en orientaci a objectes per a fer referncia a la invocaci o crida d'una operaci? 13. Quina relaci hi ha entre l'encapsulament i l'ocultaci de la informaci? 14. Quines visibilitats podem definir per a atributs i operacions en un sistema orientat a objectes? 15. Quin mecanisme de classificaci ens permet simplificar la descripci de les classes? 16. Com podem identificar relacions d'herncia en domini? 17. Quin mecanisme ens permet treballar amb un objecte en diversos nivells d'abstracci segons les nostres necessitats? 18. Qu s una classe abstracta? 19. Una classe que no s abstracta pot tenir operacions abstractes? Per qu? 20. Una classe abstracta pot tenir operacions que no ho siguin? Per qu? 21. Quina relaci hi pot haver entre el concepte d'associaci i el de polimorfisme? 22. Com podem solucionar, en orientaci a objectes, el cas en qu una associaci t informaci addicional que no depn d'una de les instncies relacionades, sin de totes?

 FUOC PID_00171145

35

Orientaci a objectes

Solucionari
Activitats 1. Els telfons sn cadenes de carcters que, aparentment, noms poden contenir nombres, per no sn nombres en el sentit que no els percebem com a tals i no els fem servir com a tals en cap moment. Aix, per exemple, alguns trets que els distingeixen dels nombres sn:

No s el mateix el telfon 003 que el 3, tot i que s que sn el mateix nombre. Els telfons no admeten cap de les operacions habituals dels nombres. Mai no sumem, restem, multipliquem, dividim, etc. telfons, tot i que s que ho fem amb els nombres. Alguns carcters no numrics poden formar part d'un nmero de telfon. Com a mnim el carcter + que podem fer servir per a senyalitzar el prefix internacional d'un nmero de telfon, i que realment es marca en marcar el nmero.

2. Classes que podem trobar i atributs:

Producte: nom:String, marcaComercial:String, descripcio:String, fotografia:Imatge, preu:Import Producte electrnic: fitxer:Fitxer, format:Format Categoria: nom:String, descripcio:String Usuari: nomUsuari:String, contrassenya:String, adrea:Adrea Compra: data:Data

Associacions: PertanyA: cada producte (amb nom de rol productes) pertany a una o ms categories (amb nom de rol categories). Fa: cada usuari (nom de rol usuari) fa un seguit de compres (nom de rol compres). Inclou: una compra (nom de rol compra) inclou un seguit de productes (nom de rol productes). Aquesta s una classe associativa amb l'atribut numUnitats:nat.

Hi ha una relaci d'herncia entre Producte i Producte electrnic, de tal manera que Producte electrnic s una subclasse de Producte. Producte, per, no s una classe abstracta, ja que hi ha productes que no sn electrnics. 3. a) Tots b) Matrcula i marca, ja que marca s protegit i s visible des de les subclasses per model s privat i no s visible des de cap altra classe que no sigui Vehicle. c) Matrcula, ja que marca i model no sn pblics. 4. a) S. Un contribuent pot tenir associat qualsevol nombre de bns i els bns immobles tamb sn bns. b) No, ja que els bns que no sn immobles no es poden hipotecar; s a dir, l'operaci noms est definida per a la classe BeImmoble i, per tant, noms es pot invocar sobre instncies d'aquesta classe. c) S. Tot b immoble s un b i, per tant, com tots els bns, t un valor. Vist des del punt de vista de l'herncia, la classe BeImmoble hereta l'atribut valor de la classe Be. d) En general, no. Noms aquells bns que siguin immobles tindran referncia cadastral. Per tots els altres no en tindran. 5. La visibilitat d'un atribut no en canvia el comportament pel que fa a l'herncia. Per tant, si valor s un atribut privat, tots els bns continuaran tenint valor, incloent-hi els bns immobles. Ara b, com que l'atribut valor s ara privat, encara que els bns immobles tamb en tinguin, no hi podem accedir des de la classe BeImmoble. Exercicisd'autoavaluaci 1. Els llenguatges de programaci procedimentals fan una abstracci del que la mquina pot entendre, mentre que els llenguatges de programaci orientats a objectes fan una abstracci d'all que les persones volen comunicar. (Vegeu el subapartat 1.2.) 2. L'anlisi orientada a objectes consisteix a aplicar els conceptes i idees dels llenguatges de programaci orientats a objectes a l'anlisi de sistemes. Per tant, l'anlisi orientada a objectes fa servir el mateix paradigma, l'orientaci a objectes, que la programaci orientada a objectes. (Vegeu el subapartat 1.3.)

 FUOC PID_00171145

36

Orientaci a objectes

3. El criteri pel qual la classificaci agrupa objectes en classes s el conjunt de responsabilitats en com que tenen aquests objectes. Aix, tots els objectes d'una mateixa classe tenen unes mateixes responsabilitats. (Vegeu el subapartat 2.1.) 4. Un objecte pot tenir responsabilitats de dades (coses que ha de saber), associacions (altres objectes que coneix) i comportament (tasques que se li poden demanar). (Vegeu el subapartat 2.1.) 5. L'abstracci. s el mecanisme mitjanant el qual decidim quines de les possibles responsabilitats associades a una classe formaran part de la seva definici. (Vegeu el subapartat 2.2.) 6. Els atributs. (Vegeu el subapartat 2.3.1.) 7. Els atributs solen tenir un tipus, que ens ajuda a entendre el tipus d'informaci que s'hi emmagatzema, un mbit (que pot ser d'instncia o de classe) i un nombre de valors (pot ser o no opcional i pot ser o no multivaluat). (Vegeu el subapartat 2.3.1.) 8. Vol dir que si una instncia a1 d'una classe A est associada amb una instncia b1 de la classe B, la instncia b estar tamb associada a la instncia a . (Vegeu el subapartat 2.3.2.) 9. Si, i s'anomena associaci recursiva. Per a distingir el rol que t cada instncia de l'associaci fem servir els rols d'associaci. (Vegeu l'apartat 2.3.2.) 10. Mitjanant operacions. (Vegeu el subapartat 2.3.3.) 11. Les operacions indiquen quines tasques pot dur a terme un objecte i formen la interfcie de l'objecte. Cada mtode s el conjunt d'instruccions que indica com un objecte du a terme una tasca (una operaci) i forma la implementaci de l'objecte. (Vegeu el subapartat 2.3.3.) 12. Tamb es fa servir la metfora de l'enviament d'un missatge. Quan un objecte invoca o crida una operaci d'un altre objecte tamb podem dir que li envia un missatge. (Vegeu el subapartat 2.3.3.) 13. L'encapsulament s el mecanisme de l'orientaci a objectes que ens permet ocultar informaci. 14. Visibilitat pblica (qualsevol objecte hi t accs), privada (noms els objectes de la mateixa classe), protegida (noms els objectes de la mateixa classe o d'alguna subclasse) i de paquet (noms els objectes del mateix grup o "paquet"). (Vegeu el subapartat 3.2.) 15. L'herncia. Ens permet simplificar la descripci d'una classe identificant responsabilitats comunes entre les instncies de diferents classes i evitant haver-les de descriure en ms d'una classe. (Vegeu l'apartat 4.1.) 16. Mitjanant la generalitzaci (trobem classes ms generals a partir de les que ja tenim) o l'especialitzaci (trobem classes ms especfiques a partir de les que ja tenim). (Vegeu el subapartat 4.1.1.) 17. El polimorfisme. s la capacitat de treballar amb un objecte amb formes diferents (interfcies diferents) segons les nostres necessitats. (Vegeu el subapartat 4.2.) 18. Una classe abstracta s una classe que no podem instanciar directament; s a dir, noms podem crear instncies d'alguna de les seves subclasses. (Vegeu el subapartat 4.2.1.) 19. Una classe no abstacta no pot tenir operacions abstractes, perqu, per a aquestes, el comportament (el mtode) s'ha de definir en les subclasses. Per tant, els objectes de la classe no tindran cap comportament associat, tret que pertanyin a una subclasse. Per aix, per fora, haurien de pertnyer a una subclasse; s a dir, la classe hauria de ser abstracta. (Vegeu el subapartat 4.2.1.) 20. Una classe abstracta pot tenir operacions que no ho siguin. Senzillament, les seves subclasses heretaran les operacions amb el seu comportament i el podran redefinir o deixar-lo tal qual. (Vegeu el subapartat 4.2.1.) 21. Podem tenir associacions polimrfiques: Una associaci polimrfica s una associaci amb una classe que t subclasses. En aquest cas, un objecte pot tenir associats, per una mateixa associaci, objectes de la classe associada i de les seves subclasses. Per tant, tindr associats objectes de diverses classes (amb una superclasse en com). (Vegeu el subapartat 4.2.2.) 22. Fem servir una classe associativa, s a dir, una classe les instncies de la qual sn instncies de l'associaci. (Vegeu l'apartat 2.3.2.)
1 1

 FUOC PID_00171145

37

Orientaci a objectes

Glossari
abstracci f L'acte de reunir les qualitats essencials o generals de coses similars. Tamb, les caracterstiques essencials provinents d'una cosa. abstracta (classe) f Classe que no es pot instanciar directament, sin que noms es poden instanciar les subclasses no abstractes que tingui. abstracta (operaci) f Operaci que no t associat un mtode; s a dir, per a la qual no s'ha definit un comportament. mbit (d'un atribut) m Caracterstica que distingeix si un atribut emmagatzema un valor diferent per a cada instncia (mbit d'instncia) o b un mateix valor per a totes les instncies d'una classe (mbit de classe). anlisi orientada a objectes f Aplicaci dels conceptes i idees dels llenguatges orientats a objectes a l'anlisi de sistemes. associaci f Relaci estructural entre dues (o ms) classes que ens indica quins objectes de la segona classe coneixen els objectes de la primera. Una associaci, per tant, constitueix una responsabilitat de cada una de les classes implicades. associaci polimrfica f Vegeu polimrfica (associaci) associaci recursiva f Associaci que connecta una classe amb ella mateixa. atribut m Element estructural d'una classe que indica quina informaci tenen les instncies d'aquella classe; s una de les responsabilitats, per tant, de la classe. caixa blanca f Tipus de descripci d'un objecte en qu es descriu, a ms de qualsevol aspecte extern de l'objecte, la seva estructura i funcionament interns. caixa negra f Tipus de descripci d'un objecte en qu es descriu el seu funcionament des d'un punt de vista extern, sense explicar-ne l'estructura ni el funcionament interns. classe abstracta f Vegeu abstracta (classe) classe associativa f Classe de la qual les instncies sn instncies d'una associaci; s a dir, cada instncia d'una classe associativa representa una instncia d'una associaci en el sentit que est formada pel parell (en el cas d'associacions binaries) d'instncies associades, a ms de tenir els atributs, associacions i operacions propis. classe (d'objectes) f Descriptor d'un conjunt d'objectes que comparteixen els mateixos atributs, associacions, operacions i mtodes. classificaci f Mecanisme d'identificar classes d'objectes com a descriptores de conjunts d'objectes amb les mateixes responsabilitats. codi mquina m Codi format pel conjunt d'instruccions que els processadors (en general, el maquinari) poden entendre i executar. cridar f Vegeu invocar. de paquet (visibilitat) Visibilitat d'un atribut, associaci o operaci tal que noms s visible pels objectes del mateix grup o paquet. encapsulament m Mecanisme de l'orientaci a objectes que ens permet ocultar informaci definint quins atributs, operacions i associacions d'un objecte sn visibles i quins resten ocults. especialitzaci f Procs d'identificaci d'una subclasse d'una classe existent que serveix per a descriure les responsabilitats comunes a un subconjunt de les instncies de la classe original, per no a totes. generalitzaci f Procs d'identificaci d'una superclasse de dues o ms classes ja existents que serveix per a descriure les responsabilitats comunes a les classes ja identificades inicialment. herncia f Caracterstica de l'orientaci a objectes mitjanant la qual podem identificar una relaci entre una superclasse i una subclasse tal que totes les instncies de la subclasse ho sn tamb de la superclasse. Diem que la subclasse hereta la definici de la superclasse,

 FUOC PID_00171145

38

Orientaci a objectes

de tal manera que per a definir la subclasse noms ens cal indicar aquelles caracterstiques que li sn especfiques que no sn presents a la superclasse. implementaci (d'una classe) f Comportament intern de les instncies d'una classe que queda definit pel conjunt de mtodes de la classe. La implementaci queda oculta darrere la interfcie. instncia f Vegeu objecte. interfcie f Conjunt d'operacions ofertes per les instncies d'una classe i que, per tant, sn invocables per altres objectes. La interfcie no inclou, per, la implementaci, que est formada pels mtodes que implementen aquestes operacions. invocar v Demanar a un objecte l'execuci del seu comportament per a una determinada operaci. llenguatge assemblador m Llenguatge de programaci en qu les instruccions es corresponen prcticament una a una amb les operacions que pot entendre el processador. Es tradueix a codi mquina per a ser executat. llenguatge de programaci m Llenguatge artificial que est dissenyat per a expressar els cmputs que volem que dugui a terme un ordinador. llenguatge de programaci d'alt nivell m Llenguatge de programaci ms ric que el llenguatge assemblador, ja que permet expressar les instruccions amb un nivell d'abstracci ms alt. llenguatge de programaci orientat a objectes m Llenguatge de programaci d'alt nivell que eleva el nivell d'abstracci creant una abstracci del problema que es vol resoldre fent servir el paradigma de l'orientaci a objectes. Vegeu orientaci a objectes. llenguatge natural m Llenguatge que fem servir les persones per a comunicar-nos entre nosaltres (com ara el catal o l'angls), per oposici als llenguatges que fem servir per a comunicar-nos amb els ordinadors (com ara els llenguatges de programaci). llenguatge procedimental m Llenguatge de programaci d'alt nivell que eleva el nivell d'abstracci creant una abstracci de la mquina sobre la qual s'executen. Permet fer servir un joc d'instruccions ms abstractes que les que el processador s directament capa d'executar. llenguatge unificat de modelitzaci m Vegeu universal modeling language mtode m Conjunt d'instruccions que, per a una operaci, en una classe, indica com es comportaran els objectes d'aquella classe. El conjunt dels mtodes de la classe en forma la implementaci. missatge (orientaci a objectes) m Metfora que representa una crida o invocaci d'una operaci d'un objecte. Sota aquesta metfora diem que l'objecte que fa la crida (el que demana l'execuci de l'operaci) envia un missatge a l'objecte que rep la crida (el que ha d'executar el seu comportament per a aquella operaci). multivaluat (atribut) m Atribut que, per a una determinada instncia, pot tenir ms d'un valor en lloc d'haver-ne de tenir noms un. Antnim d'univaluat. objecte m Cada un dels elements autnoms que forma un sistema orientat a objectes obligatori (atribut) m Atribut tal que totes les instncies de la classe hi han de tenir valor. Antnim d'opcional. ocultaci d'informaci f Capacitat de fer que cada element d'un sistema contingui certa informaci que s'amaga a la resta d'elements, mostrant-los una visi simplificada. En el cas de les classes d'un sistema orientat a objectes, l'encapsulament permet indicar quins elements sn visibles i ocultar la resta. opcional (atribut) m Atribut que, per a una determinada instncia, pot no tenir valor. Si un atribut no s opcional, aleshores ha de tenir valor per a totes les instncies de la classe. Antnim d'obligatori. operaci f Especificaci d'una tasca que poden dur a terme totes les instncies d'una classe. L'operaci es pot demanar mitjanant la crida o invocaci i el comportament de la instncia que rebi la crida es defineix en un mtode. s, per tant, una de les responsabilitats de la classe.

 FUOC PID_00171145

39

Orientaci a objectes

operaci abstracta f Vegeu abstracta (operaci) operaci polimrfica f Vegeu polimrfica (operaci) orientaci a objectes f Paradigma consistent a descompondre un sistema complex en un conjunt d'elements autnoms (els objectes) que es comuniquen els uns amb els altres per tal de dur a terme les seves tasques. paquet m Agrupaci d'elements en un sistema orientat a objectes per a facilitar-ne l'organitzaci. Un paquet pot contenir classes i altres paquets i pot resultar til per a definir la visibilitat de paquet dels atributs, associacions i operacions de les classes que cont. polimrfica (associaci) f Associaci en qu una (o ms) de les classes que hi participen t subclasses, de tal manera que un objecte pot tenir associats, per la mateixa associaci, objectes pertanyents a diferents classes (sempre que pertanyin a la jerarquia d'herncia de la classe associada). polimrfica (operaci) f Operaci que t un mtode associat en una classe per que t un mtode diferent per a alguna de les subclasses de la classe. D'aquesta manera, les diferents instncies de la classe, en executar l'operaci, es comportaran de manera diferent en funci de si sn instncies noms de la classe o de quina subclasse siguin instncies. polimorfisme m Capacitat d'un objecte de presentar-se amb formes diferents (interfcies diferents) segons el context. Aix, un objecte que pertanyi a una classe qualsevol es pot veure com a pertanyent a aquella classe, a la superclasse d'aquella, a la superclasse de la superclasse d'aquella, etc. protegida (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que noms s visible per la classe en qu est definida i les seves subclasses. privada (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que noms s visible per la mateixa classe en qu est definida. pblica (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que s visible per tots els objectes del sistema. redefinir (una operaci) v Definir, per a una operaci d'una subclasse, un mtode (un comportament) diferent del mtode que tenia associada aquella operaci a la superclasse. En redefinir una operaci en una subclasse la convertim en una operaci polimrfica. responsabilitat (d'un objecte) f Caracterstiques o obligacions d'una classe, que poden ser informaci que les instncies han de conixer (atributs), altres instncies que han de conixer (associacions) o tasques que han de poder dur a terme (operacions). rol m Extrem d'una associaci al qual s'assigna un nom per a indicar el seu propsit; s a dir, per a indicar quin s el paper que hi tenen les instncies quan s'associen. subclasse f En una relaci d'herncia entre dues classes, la classe que hereta les responsabilitats de l'altra classe; s, per tant, la classe ms especfica. superclasse f En una relaci d'herncia entre dues classes, la classe de la qual s'hereten les responsabilitats; s, per tant, la classe ms genrica. tipus (d'un atribut) m Descripci del conjunt de valors que pot prendre un atribut. Alguns exemples de tipus d'atributs poden ser el tipus data (que defineix un conjunt de valors que inclou 1/3/2011 o 31/3/1414), enter (com ara 14 o 356) o carcter (com ara "a" o "@"). unified modeling language mLlenguatge de modelitzaci de propsit general estandarditzat per l'OMG i utilitzat en el camp de l'enginyeria del programari. Sigla UML univaluat (atribut) m Atribut tal que cap instncia de la classe no pot tenir ms d'un valor en aquell atribut. Antnim de multivaluat. visibilitat f Propietat d'un atribut, associaci o operaci que defineix quins objectes el poden veure o veure-la. La visibilitat pot ser pblica, privada, protegida o de paquet.

 FUOC PID_00171145

40

Orientaci a objectes

Bibliografia
La bibliografia sobre orientaci a objectes est molt relacionada amb el mn de la programaci. Meyer, Bertrand (2002). Construccin de software orientado a objetos. Madrid: Prentice Hall. Aquest llibre s la referncia acadmica en orientaci a objectes i, per tant, s molt adequat per a l'estudi en profunditat dels diferents conceptes. Bibliografia complementria Moltes guies i llibres sobre programaci en un llenguatge orientat a objectes inclouen una secci introductria sobre la programaci a objectes. A continuaci us en recomanem dos: Eckel, Bruce (2006). Thining in Java. Prentice Hall. Object Oriented Programming with Objective C (Apple Corp.) http://developer.apple.com/mac/ library/documentation/Cocoa/Conceptual/OOP_ObjC/OOP_ObjC.pdf Referncies bibliogrfiques Parnas, David L. (1972). "On the Criteria to Be Used in Decomposing Systems Into Modules". Communications of the ACM.