Pid 00161675

Clases y objetos
Jordi Brnquez Jimnez

Miquel ngel Piera i Eroles
Juan Jos Ramon Gonzlez
PID_00161675
FUOC PID_00161675 Clases y objetos
ndice
Introduccin ............................................................................................ 5
Objetivos ................................................................................................... 6
1. Criterios de calidad .......................................................................... 7

1.1. Factores de calidad internos ........................................................... 8
1.2. Factores de calidad externos ........................................................... 8
1.2.1. Reutilizacin de cdigo ....................................................... 8
1.2.2. Escalabilidad de la aplicacin ............................................. 9
1.2.3. Portabilidad del cdigo ....................................................... 10
1.2.4. Usabilidad ............................................................................ 10
1.2.5. Funcionalidad ..................................................................... 11
1.3. Otros factores de calidad ................................................................ 11
1.3.1. Precisin ............................................................................... 11
1.3.2. Robustez ............................................................................... 12
1.3.3. Compatibilidad .................................................................... 12
1.3.4. Rendimiento......................................................................... 13
1.3.5. Oportunidad......................................................................... 13
1.4. El papel de la orientacin a objetos ................................................ 14
2. El principio de modularidad ......................................................... 21

2.1. Requerimientos de modularidad .................................................... 15
2.1.1. Descomposicin .................................................................. 15
2.1.2. Composicin ....................................................................... 16
2.1.3. Comprensin ...................................................................... 17
2.1.4. Continuidad ........................................................................ 17
2.1.5. Proteccin ............................................................................ 18
2.2. Reglas de modularidad ................................................................... 18
2.2.1. Mapeo directo ..................................................................... 18
2.2.2. Limitacin del nmero de interfaces .................................. 19
2.2.3. Limitacin del tamao de las interfaces ............................. 19
2.2.4. Facilidad de reconocimiento de las interfaces ................... 19
2.2.5. Ocultacin de la informacin ............................................. 20
3. Clases y objetos .................................................................................. 21

3.1. Los papeles de la clase y del objeto ................................................ 21
3.2. La clase como estructura esttica ................................................... 23
3.2.1. Atributos .............................................................................. 24
3.2.2. Mtodos u operaciones ....................................................... 25
3.2.3. Visibilidad de los atributos y mtodos ................................ 26
3.2.4. La clase como estructura modular ...................................... 27
3.2.5. Representacin de una clase con UML ............................... 28
3.3. El objeto como estructura dinmica ............................................... 29
FUOC PID_00161675 Clases y objetos
3.4. Extensin de los atributos y de los mtodos de una clase ............. 31

3.4.1. Los mtodos constructor y destructor de una clase ............ 32
3.5. Sobrecarga ....................................................................................... 33
3.6. Otros aspectos sobre los lenguajes de programacin
orientada a objetos ......................................................................... 34
Resumen .................................................................................................... 35
Ejercicios de autoevaluacin ............................................................... 37
Solucionario ............................................................................................. 38
Bibliografa .............................................................................................. 38
FUOC PID_00161675 5 Clases y objetos
Introduccin
Una de las diferencias principales de los proyectos informticos respecto de los

proyectos de otras reas de conocimiento (arquitectnicos, aeronuticos, in-
dustriales, etc.) es que los objetivos que han motivado el desarrollo de una
aplicacin informtica cambian al mismo tiempo que las necesidades de los
usuarios.
La aproximacin clsica al diseo y la implementacin de proyectos inform-

ticos era cerrada: inicialmente se desarrollaba un documento de especificacio-
nes en el que se recoga la funcionalidad de la aplicacin y, a continuacin, se
pasaba a la etapa de diseo e implementacin. Desgraciadamente, en el caso
de los proyectos informticos, los objetivos cambian con mucha facilidad, en
cualquier momento desde que se conciben hasta que se entregan. Muchos de
estos cambios se producen, entre otros motivos, porque los usuarios o clientes
no siempre tienen claro al principio del proyecto qu funcionalidad tiene que
ofrecer el programa y, ms en general, porque suelen aparecer ideas nuevas a
medida que los usuarios se integran en el proyecto, o despus de algn tiempo
de haberlo utilizado.
Algunos de los aspectos que han puesto de manifiesto las limitaciones de la

metodologa clsica de desarrollo del software son: la evolucin constante de
las aplicaciones informticas para adaptarlas a nuevos requerimientos (tanto
tecnolgicos como funcionales), la necesidad de rentabilizar al mximo las
horas de programacin, y la capacidad de prever con exactitud las fechas de en-
trega de las aplicaciones.
Para atender las necesidades de las empresas de software y hacer que las apli-
caciones informticas sean viables econmicamente, es necesario facilitar la
reutilizacin de programas minimizando el trabajo de hacer adaptaciones a las
funcionalidades nuevas. Un prerrequisito para facilitar la reutilizacin es que
el software desarrollado responda a ciertos criterios de calidad.
En los apartados 1 y 2 de este mdulo didctico presentamos los criterios de

calidad que facilitarn la reutilizacin de programas y prestamos atencin es-
pecialmente al concepto de modularidad, que es la base de la orientacin a ob-
jetos. En el apartado 3 explicamos cmo el paradigma de la orientacin a
objetos implementa el concepto de modularidad y potencia los factores de ca-
lidad externos.
Objetivos
Los materiales didcticos de este mdulo proporcionan los conocimientos

fundamentales para que los estudiantes alcancis los objetivos siguientes:
1. Conocer el conjunto de criterios y reglas que se tendran que cumplir en la

etapa de anlisis y diseo de una aplicacin informtica.
2. Aproximarse al concepto de modelo de la realidad definida por el problema

que se quiere resolver como paso previo a cualquier consideracin sobre la
implementacin de una aplicacin.
3. Conocer los mecanismos de representacin en los que se basa la orienta-

cin a objetos.
1. Criterios de calidad
En general, se puede decir que, cuando se aprende a programar, los primeros

ejemplos suelen consistir en un nico programa (programa principal) que
contiene todo el cdigo (secuencia de instrucciones) y que actualiza los datos
almacenados en variables globales a las cuales se puede acceder desde cual-
quier instruccin del programa.
Programacin no estructurada
La tcnica de programacin que hace que el programa principal opere directa-

mente sobre los datos globales se denomina programacin no estructurada. Esta tc-
nica de programacin presenta problemas graves cuando el cdigo del programa
aumenta considerablemente de volumen para ofrecer funcionalidades nuevas.
Una consecuencia muy extendida de la programacin no estructurada es que

una misma secuencia de instrucciones se tiene que repetir varias veces. Esta
caracterstica no es deseable desde el punto de vista de la reutilizacin por-
que, adems de incrementar considerablemente el nmero de lneas de c-
digo, dificulta la identificacin de la funcin de las diferentes secuencias de
instrucciones cuando se quiere adaptar el cdigo a funcionalidades nuevas,
y tambin implica dificultad a la hora de modificar el cdigo para corregir po-
sibles errores.
Programacin procedimental
La programacin procedimental ofrece una tcnica para extraer las secuencias

de instrucciones repetitivas, darles un nombre, permitir que se ejecuten ha-
ciendo una llamada con el nombre desde cualquier punto del programa y vol-
ver a la instruccin situada despus de la llamada.
Este paradigma permite codificar diferentes funcionalidades en los programas

de manera ms estructurada, ya que un procedimiento (secuencia de instruc-
ciones) puede llamar a otros procedimientos para ejecutar tareas ms especfi-
cas. Estas llamadas (tambin denominadas invocaciones) permiten traspasar
informacin entre procedimientos.
Una buena estructuracin en el rbol de llamadas facilita mucho la tarea de

desarrollo y tambin la comprensin del funcionamiento del programa para
personas externas.
La programacin procedimental facilita considerablemente la tarea de codifi-

cacin y la identificacin de la funcionalidad de secuencias de lneas de cdi-
go, pero no facilita en absoluto la reutilizacin, ya que para implementaciones

posteriores hay que copiar el cdigo de una parte a otra.
Programacin modular
La programacin modular facilita la reutilizacin, ya que permite agrupar los

procedimientos con funcionalidades similares en mdulos separados, cada
uno con sus datos. De esta manera, cada mdulo puede manipular su estado
interno (valores de las variables) con llamadas a sus procedimientos.
Como hemos presentado ya en el mdulo anterior, la programacin clsica en-

cuentra problemas importantes a la hora de desarrollar software para aplicaciones
informticas grandes, cosa que ha forzado a mejorar la calidad de los programas
con el objetivo de disearlos y codificarlos de manera que sean eficientes, fciles
de utilizar, legibles, estructurados y modulares, entre otras cualidades.
En los dos apartados siguientes, presentaremos de manera resumida los prin-

cipales factores de calidad internos y externos del software propuestos por
Bertrand Meyer.
1.1. Factores de calidad internos
Los factores de calidad internos son aquellos que tienen que ver con la calidad
del cdigo de la aplicacin. Estos factores normalmente no son apreciados
por los usuarios finales, pero los factores externos dependen mucho de stos.
Trataremos con ms profundidad los factores de calidad internos en el aparta-

do siguiente, cuando hablemos de uno de los ms importantes: la modulari-
dad de las aplicaciones.
1.2. Factores de calidad externos
Los factores de calidad externos son aquellos que pueden ser evaluados por
un usuario final como, por ejemplo, el grado de usabilidad de la aplicacin.
1.2.1. Reutilizacin de cdigo
Ejemplos de cdigo
Se habla de cdigo reutilizable cuando una aplicacin incorpora partes reutilizable
de cdigo (estructuras, principalmente) que inicialmente haban sido
Entrada de datos
implementadas en otras aplicaciones; o tambin cuando una aplicacin Almacenamiento de datos
contiene partes de cdigo que se van a emplear en otras aplicaciones. Representaciones grficas de
los resultados
El hecho de que aplicaciones informticas diferentes presenten patrones pare-

cidos, junto con la necesidad de hacer ms rentable la industria informtica,
ha forzado a reducir el nmero de lneas de cdigo a la hora de desarrollar una
aplicacin y a maximizar la reutilizacin de mdulos precisos y robustos codi-
ficados previamente.
Podemos medir la reutilizacin del cdigo a partir de la capacidad de utilizar

estructuras de programacin definidas en el contexto de una aplicacin deter-
minada para desarrollar otras aplicaciones.
El concepto de reutilizacin es uno de los factores principales de calidad que

ha potenciado ms la orientacin a objetos: cuanto ms sencillas son las es-
tructuras de programacin, ms fcil es que se reutilicen.
1.2.2. Escalabilidad de la aplicacin
Entendemos por escalabilidad de una aplicacin la facilidad con la que

sta se puede ampliar y adaptar a los cambios en sus especificaciones y
funcionalidades.
Ciertas metodologas clsicas de ingeniera del software consideraban que un

buen anlisis de requerimientos permita confeccionar un buen documento
de especificaciones, que tena que guiar toda la etapa de diseo y codificacin.
Uno de los motivos principales de esta idea era que, en las fases iniciales de la
ingeniera del software, las tcnicas desarrolladas se centraban en formular y
solucionar problemas cerrados.
Dado que las aplicaciones normalmente no son problemas cerrados, aparecie-

ron tcnicas nuevas de ingeniera del software que reconocan como esencial
la capacidad de crear aplicaciones capaces de adaptarse a los cambios constantes
que pueden solicitar los usuarios finales.
La ampliacin de las funcionalidades de un programa pequeo, en general, no

suele ser problemtica. En cambio, a medida que las aplicaciones informticas
crecen, modificarlas es cada vez ms difcil por su complejidad.
Para mejorar la escalabilidad de una aplicacin informtica, hay dos princi-

Simplicidad
pios que conviene preservar: y descentralizacin
La orientacin a objetos ayuda

Simplicidad de diseo. Una arquitectura simple siempre ser ms fcil de a disear y codificar estructuras
simples y descentralizadas.
adaptar y modificar que una arquitectura compleja.
Descentralizacin. Cuanto ms autnomos sean los mdulos, ms probable

ser que el nmero de mdulos involucrados en un cambio sea reducido.
1.2.3. Portabilidad del cdigo
Podemos definir la portabilidad del cdigo como la facilidad de uti-

lizar un mismo programa en plataformas diferentes (hardware y soft-
ware), minimizando el esfuerzo de adaptarlo.
La mayor parte de las incompatibilidades entre plataformas no responden a

diferencias con la lgica del programa, sino que tienen que ver con las carac-
tersticas del mismo sistema (hardware y software) en el que se ejecuta la apli-
cacin. Por lo tanto, si podemos separar claramente las partes dependientes de
las independientes, las tareas de adaptar el cdigo a plataformas nuevas resul-
tan muy pequeas.
Figura 1. Esquema de aplicacin para favorecer la portabilidad
Esta manera de organizar las partes de una aplicacin se denomina programa- La orientacin a objetos facilita la
sustitucin de un mdulo por otro
cin en tres capas (o niveles). con funcionalidades equivalentes.
1.2.4. Usabilidad
Definimos la usabilidad como la facilidad con la que personas de or-

genes diferentes (culturales, de formacin, etc.) se pueden familiarizar
con el uso de la aplicacin.
Aunque no es indispensable, la usabilidad ayuda al hecho de que los usuarios

encuentren fcil trabajar con el programa y, por lo tanto, que la sensacin de
calidad que tienen aumente considerablemente.
La manera en la que se disean los programas puede facilitar la tarea de apren-

dizaje por parte de los usuarios. La orientacin a objetos ofrece metodologas
que permiten adaptar el diseo a la tipologa de los usuarios potenciales.
1.2.5. Funcionalidad
La funcionalidad de una aplicacin es la facilidad que tiene para am-

pliar las tareas que ofrece.
Es importante reconocer y aceptar que, a diferencia de otros campos de la inge-

niera, los proyectos informticos se ven sometidos constantemente a requeri-
mientos nuevos por parte de los usuarios. Desde el punto de vista de la ingeniera
del software, la ampliacin de funciones de una aplicacin que no se haban pre-
visto en la etapa del diseo puede comportar dos problemas complejos:
Incorporar funcionalidades nuevas puede hacer ms difcil localizar las

funcionalidades que los usuarios utilizan con ms frecuencia; por lo tanto,
se reduce su usabilidad.
Incrementar funcionalidades acostumbra a incluir tambin que se reestruc-

turen los datos internos. Esto puede repercutir en el resto de los factores de
calidad, ya que puede ser necesario que se modifique el diseo de la apli-
cacin para que satisfaga estas funcionalidades nuevas.
1.3. Otros factores de calidad
Hay otros factores de calidad externos que, aunque importantes para el usuario,
no tienen una implicacin directa con la metodologa de orientacin a objetos.
1.3.1. Precisin
Podemos definir la precisin como la capacidad de un programa de rea-

lizar las tareas y funcionalidades definidas en el documento de especifi-
caciones exactamente tal y como se haban definido.
Aunque puede parecer que la precisin se puede conseguir fcilmente, en reali-

dad no es as. Es muy difcil formalizar con precisin un documento de especi-
ficaciones con todos los requerimientos porque, como ya hemos comentado,
casi todas las aplicaciones informticas estn sometidas constantemente a cam-
bios y modificaciones, y las personas que las necesitan normalmente no tienen
un concepto claro de lo que necesitan.
Los mtodos para garantizar precisin suelen ser condicionales y se basan en

una aproximacin multinivel, en la que cada nivel supone que el nivel inferior
es correcto.
En la figura 2, ilustramos el concepto de aproximacin multinivel. Podis ob-

servar que los niveles superiores construyen la funcionalidad a partir de mto-
dos implementados en niveles inferiores:
Figura 2. Aproximacin multinivel de una aplicacin
1.3.2. Robustez
Un programa es robusto cuando reacciona apropiadamente a condicio-

nes de utilizacin anmalas.
Si definimos la precisin respecto de las condiciones de operacin recogidas

en el documento de especificacin, la robustez hace referencia al comporta-
miento del programa en condiciones no recogidas en ste.
Aunque la robustez es un concepto ms difuso, hay que tenerlo en cuenta en

la fase de diseo para garantizar que el programa no provocar efectos inde-
seables en situaciones imprevistas, generar mensajes de error y acabar su eje-
cucin de manera limpia. Se tienen que considerar, por ejemplo, apagones
elctricos, errores en un disco, etc.
1.3.3. Compatibilidad
La compatibilidad en programacin es la facilidad con la que se pue-

den integrar elementos de programacin desarrollados de manera inde-
pendiente.
La importancia de la compatibilidad reside en el hecho de que los elementos de

programacin no se disean para utilizarlos aisladamente, sino que necesitan
interactuar entre los mismos. Desgraciadamente, es justamente en la interac-
cin entre estos elementos (mdulos) cuando aparece gran parte de los proble-
mas, causados mayoritariamente por las suposiciones realizadas en la etapa de

diseo.
Uno de los aspectos clave para garantizar la compatibilidad es que el diseo

sea homogneo y que haya convenciones estndar para que los elementos se
comuniquen.
Por ejemplo, podemos hablar de las interfaces grficas de los diferentes siste-
mas operativos como Windows, Mac OS o GNU/Linux (con Gnome, KDE,
XFace, entre otros), que contienen mens, ventanas, iconos, etc.
1.3.4. Rendimiento
En programacin, el rendimiento se puede entender como la capaci-

dad de un programa para solicitar el mnimo nmero de recursos de
hardware con el objetivo de atender las peticiones para las cuales se ha
diseado en el mnimo de tiempo posible.
El rendimiento puede limitar otros factores de calidad como la reutilizacin o

Una mxima de programacin:
la ampliacin de funcionalidades, cosa que no pasa con el resto de los factores Hazlo fcil antes que hacerlo
rpido.
de calidad explicados hasta ahora. Es fcil darse cuenta de que, para ofrecer un
rendimiento elevado, hay que codificar soluciones especficas para cada pro-
blema, de manera que cualquier cambio, por pequeo que sea, puede ser muy
complejo.
De la misma manera que no es aconsejable centrarse slo en los aspectos de rendimiento

del software durante la etapa de diseo, tampoco lo es obviarlos porque se supone que
en breve el hardware ir el doble de rpido.
Muchos usuarios, por ejemplo, no compran hardware ms potente para realizar una cier-
ta tarea en la mitad de tiempo, sino para someter el mismo programa a problemas ms
complejos en el mismo tiempo.
Si en la etapa de diseo no se han tenido en cuenta aspectos relativos a la eficiencia del

programa, difcilmente un hardware ms rpido permitir satisfacer las necesidades nue-
vas del usuario.
En estos materiales, potenciaremos la reutilizacin y la ampliacin por encima

del rendimiento.
En el ao 1996,
1.3.5. Oportunidad Microsoft...
... entregaba la versin de su

sistema operativo un mes antes
de lo previsto, despus de aos
La oportunidad es la habilidad de entregar una aplicacin cuando el
de desarrollo, y el anuncio me-
mercado la solicita o cuando un grupo de usuarios la necesita. Es uno reci una portada en Computer
World.
de los factores ms crticos desde el punto de vista de la viabilidad eco- NT 4.0 Beats Clock.
nmica de un proyecto de software. Computer World (vol. 30,
nm. 30, julio de 1996).
1.4. El papel de la orientacin a objetos
Como se ha podido ver en la descripcin de los criterios de calidad, el diseo

y la implementacin de aplicaciones informticas no son tareas triviales y
tampoco parece que se puedan abordar con xito con mtodos clsicos de pro-
gramacin: requieren una filosofa y una manera de entender los problemas
que permita atender eficientemente el contexto dinmico impuesto por los
cambios tecnolgicos constantes.
El modelado y diseo orientado a objetos es una manera nueva de pensar, en

Se hacen maquetas...
la que se utilizan modelos para representar conceptos del mundo real. La
... en arquitectura, automo-
orientacin a objetos ofrece una metodologa de diseo y programacin que cin, etc. que sirven para estu-
facilita que se desarrollen y se codifiquen modelos de entidades reales. diar ciertos aspectos sin tener
que construir el modelo
a tamao real.
Desarrollar modelos que representen sistemas fsicos o elementos del mundo
real no es una actividad propia y nueva en el campo de la informtica, sino
que se ha utilizado con xito en muchos otros campos de la ingeniera.
El concepto fundamental es el objeto, entendido como una combina-

cin de estructuras de datos y comportamiento en una nica entidad.
Un objeto es un mdulo con datos y operaciones que modela una en-

tidad que hay en un mundo, fsico o virtual, que tiene sentido para el
usuario.
2. El principio de modularidad
Como ya hemos comentado, el cumplimiento de muchos de los criterios de

calidad introducidos en el apartado anterior depende en gran manera de la
modularidad de las estructuras de representacin, tanto de cdigo como de da-
tos, en las que podemos basar el desarrollo de una aplicacin.
En este apartado, discutiremos los criterios que se tienen que cumplir para que Relacionaremos la modularidad
con el concepto de clase en el
una estructura de representacin se pueda calificar de modular y, por lo tanto, apartado siguiente.
permita una metodologa de desarrollo modular.
La programacin modular se haba entendido originalmente como el desarro-

llo de programas a partir de acoplar pequeas piezas de cdigo, denominadas
subrutinas, que al mismo tiempo se agrupaban en mdulos cuando stas tra-
bajaban con los mismos datos. Esta tcnica, sin embargo, no garantiza los be-
neficios que derivan de la escalabilidad y la reusabilidad.
Un mtodo de desarrollo de software es modular si ayuda a disear pro-

gramas que se pueden implementar conectando, de manera coherente y
mediante estructuras simples, elementos de programacin autnomos.
En este apartado profundizaremos en esta definicin informal, y nos centrare-

mos en aquellas propiedades y caractersticas que debe tener un mtodo para
garantizar la modularidad: os presentaremos cinco requerimientos y cinco re-
glas, cuya combinacin permite garantizar que se cumplen los requerimientos
ms importantes de una metodologa de diseo modular.
El concepto de mdulo se tiene que entender como la unidad bsica de des-

composicin de una aplicacin informtica. Un mdulo se debe disear de
acuerdo con los criterios y las reglas que exponemos a continuacin.
2.1. Requerimientos de modularidad
2.1.1. Descomposicin
Un mtodo de programacin preserva la descomposicin modular si fa-

cilita que se divida un problema de programacin en un nmero peque-
o de subproblemas menos complejos, interconectados por estructuras
sencillas y suficientemente independientes para poder ser tratados indi-
vidualmente.
Esta definicin permite aplicar el concepto de descomposicin de manera re-

cursiva: si un subproblema todava presenta un cierto nivel de complejidad, se
puede continuar descomponiendo en un conjunto de subproblemas nuevos.
ste es uno de los conceptos principales dentro de los mtodos de programa-
cin, y es conocido como diseo descendente.
En cambio, hay otros mtodos que recomiendan utilizar un mdulo de inicia-

lizacin global. No se puede decir que preserven la descomposicin modular
porque eliminan la autonoma de los mdulos, ya que el mdulo de iniciali-
zacin tiene que acceder a los datos internos de los otros mdulos.
En la metodologa de orientacin a objetos, cada mdulo es el respon-

sable de inicializar correctamente su estructura de datos.
Una de las grandes ventajas de la descomposicin modular es que, puesto que

la codificacin de cada mdulo es independiente, se puede distribuir la tarea
de programacin entre varios programadores o equipos de trabajo, y asignar
un subsistema a cada uno. Evidentemente, esto requiere una gran simplicidad
en las estructuras de conexin entre mdulos:
Las dependencias entre mdulos tienen que ser mnimas; en caso contra-
rio, desarrollar un subsistema puede requerir que se implementen correc-
tamente otros subsistemas.
Las dependencias entre mdulos se tienen que conocer y se deben forma-

lizar correctamente; en caso contrario, al final del proyecto, se dispondr
de un conjunto de mdulos que funcionan correctamente de manera indi-
vidual, pero que no se pueden acoplar entre s.
2.1.2. Composicin
La composicin modular se puede entender como el problema inverso de la

descomposicin modular. De todos modos, es importante puntualizar que
la composicin es independiente de la descomposicin.
Un mtodo de programacin preserva la composicin modular si faci-

lita el diseo de elementos de programacin que se pueden combinar
entre s para desarrollar aplicaciones informticas nuevas en campos di-
ferentes de los que se haban desarrollado originalmente.
La composicin modular est vinculada directamente al factor de calidad de

reutilizacin: el objetivo es buscar mecanismos que permitan disear elemen-
tos de programacin que respondan a tareas y funciones bien definidas, y que

sean reutilizables en una gran diversidad de contextos.
Un ejemplo de composicin modular son las bibliotecas de sistema, que contienen un

conjunto de elementos de programacin que se reutilizan en infinidad de aplicaciones.
2.1.3. Comprensin
Un mtodo de programacin preserva la comprensin modular si fa-

cilita el diseo de elementos de programacin que se pueden interpre-
tar fcilmente sin tener que conocer el resto de los mdulos.
Dos aspectos muy vinculados a la comprensin modular son los siguientes:
La documentacin de componentes reutilizables.
La indexacin y la gestin de componentes reutilizables, de manera que se

pueda identificar el ms conveniente a las necesidades concretas del pro-
gramador.
2.1.4. Continuidad
Un mtodo preserva la continuidad si un cambio pequeo en alguna

de las especificaciones del problema repercute en cambios en un nico
mdulo o en un nmero reducido de mdulos.
Para entender mejor la continuidad, se tiene que relacionar con el campo del
anlisis matemtico. Una funcin continua tiene la caracterstica de que un
cambio pequeo en el argumento comporta un cambio proporcionalmente
pequeo en el resultado. En programacin, se utiliza el concepto por analoga,
es decir, un cambio pequeo en la especificacin tiene que comportar un cam-
bio pequeo en la implementacin de la aplicacin.
Si aceptamos que los requerimientos de un proyecto informtico cambiarn

de manera inevitable a medida que el proyecto progrese, es muy importante
que utilicemos una metodologa que garantice la continuidad.
Un ejemplo de continuidad lo podemos encontrar en el criterio, ya muy extendido entre

los programadores, de utilizar constantes para almacenar ciertos valores en lugar de uti-
lizar directamente estos valores dentro del cdigo del programa, de manera que cada vez
que convenga cambiar un valor, el programador slo tendr que cambiar la definicin
de la constante.
2.1.5. Proteccin
La proteccin hace referencia a la propagacin de errores entre los m-

dulos, no a la manera de evitar y corregir errores de ejecucin fruto de
problemas de hardware o del mal uso del programa (entradas errneas).
Los efectos de los errores son un factor clave en el xito o fracaso de una
aplicacin informtica.
Un mtodo de programacin preserva la proteccin modular si facilita el dise-

o de arquitecturas que limitan los efectos de una condicin anormal de ope-
racin durante el tiempo de ejecucin en el mdulo en el que se ha producido
el problema o, como mximo, permiten que se propaguen a los mdulos con
los que interacta directamente.
Un ejemplo de diseo con proteccin modular lo encontramos en las aplicaciones que

disean los mdulos responsables de aceptar datos del usuario, de manera que los vali-
den antes de procesarlos y transferirlos a otros mdulos de la aplicacin.
2.2. Reglas de modularidad
Teniendo en cuenta los criterios de anlisis, diseo y programacin presenta-

dos, hay cinco reglas que hacen referencia a la conexin entre programas y a
la interaccin entre mdulos, que se deben preservar para garantizar la modu-
laridad.
2.2.1. Mapeo directo
Cualquier aplicacin informtica se intenta desarrollar atendiendo a las nece-

sidades inherentes del dominio del problema que se quiere solucionar. Es de-
cir, si se dispone de un buen modelo que formaliza correctamente el dominio
del problema, se tiene que mantener una correspondencia con la estructura de
la solucin formalizada en el programa.
La estructura modular que se obtiene aplicando una metodologa tiene

que ser compatible con la que se obtiene en la etapa de modelizacin
del problema.
Esta regla es una consecuencia directa de los criterios de modularidad si-

guientes:
Continuidad. Si hay una relacin directa entre la estructura del problema

y la estructura de la solucin, es ms fcil prever y limitar los efectos de un
cambio en los requerimientos.
Descomposicin. El anlisis de la estructura del problema suele ofrecer un

buen punto de inicio para conseguir una buena descomposicin modular
de la aplicacin informtica.
2.2.2. Limitacin del nmero de interfaces
La comunicacin entre mdulos acostumbra a materializarse de diferentes

maneras: comparticin de datos, llamadas entre mdulos, etc. Por lo tanto,
para facilitar las tareas de programacin, hay que limitar el nmero de co-
nexiones entre objetos. Si una aplicacin est compuesta por n mdulos, el
nmero mximo de conexiones es (n * (n 1) / 2); tenemos que intentar rehuir
este valor y acercarnos al mximo al nmero mnimo de relaciones (n 1).
La regla ms importante de la limitacin de interfaces nos recomienda

que cualquier mdulo se comunique con la mnima cantidad posible de
mdulos.
Esta regla es consecuencia de los criterios de continuidad y proteccin, ya que

los efectos de un error o de un cambio en los requerimientos se pueden limitar
ms fcilmente si el nmero de conexiones entre mdulos es reducido.
2.2.3. Limitacin del tamao de las interfaces
Si dos mdulos deben comunicarse necesariamente, hay que limitar al

mximo la cantidad de informacin intercambiada.
Esta regla limita el tamao de la informacin intercambiada entre mdulos,

no el nmero de canales de comunicacin, como hace la regla anterior.
Usar variables globales a las cuales se puede acceder desde cualquier mdulo
es contrario a la metodologa de desarrollo modular que utilizaremos en esta
asignatura.
2.2.4. Facilidad de reconocimiento de las interfaces
La comunicacin entre mdulos tiene que ser pblica y reconocible. Es

decir, las interfaces deben ser explcitas.
Si la comunicacin entre mdulos es explcita, se facilita que cualquier nece-

sidad de comunicacin entre mdulos detectada en la etapa de diseo se re-
fleje en el diseo de una interfaz, de manera que se preserva la composicin y
la descomposicin.
Esta identificacin tambin facilita que se detecten los mdulos que se pueden
ver afectados por un cambio en las especificaciones del problema se preserva
la continuidad.
Finalmente, facilita tambin la comprensin del problema porque se pueden

identificar las dependencias entre mdulos fcilmente.
2.2.5. Ocultacin de la informacin
En la etapa de diseo de un mdulo, es imprescindible especificar el conjunto

de las propiedades del mdulo que constituirn la informacin a la cual ten-
drn acceso los otros mdulos.
Estas propiedades las podemos dividir en dos tipos, propiedades pblicas y

propiedades privadas:
Las propiedades pblicas son aquellas que los usuarios de nuestro mdulo
pueden consultar y modificar directamente.
En cambio, las propiedades privadas son aqullas a las cuales slo puede
acceder el programador. El usuario no tiene por qu conocer que estn.
Es importante identificar las propiedades pblicas y privadas de los mdu-

los porque, justamente, las propiedades pblicas son las que constituirn
la interfaz del mdulo y, por lo tanto, sern las que los otros mdulos (ob-
jetos) debern conocer.
Esta regla ayuda a preservar el principio de continuidad: si un cambio en la es-

pecificacin del problema slo afecta a las propiedades privadas de un mdu-
lo, no ser necesario revisar ni modificar el cdigo del resto de los mdulos.
Cuanto menor es la parte pblica de un mdulo, ms probable es que

los cambios de especificaciones tan slo afecten a las propiedades priva-
das, cosa que facilita tanto la reutilizacin de los mdulos como su
mantenimiento.
3. Clases y objetos
En los apartados anteriores, hemos establecido las bases en las que se funda-
Un tipo abstracto de datos
menta la aplicacin de la metodologa de orientacin a objetos con el fin de (TAD)
alcanzar un buen nivel de calidad en el software. De la misma manera, han ... es una abstraccin del con-
cepto tradicional de tipo de
servido para establecer el marco en el que se sita la clase como estructura de datos presente en todos los
representacin. lenguajes de programacin, y
su utilidad principal reside en
el hecho de que permiten defi-
nir cmodamente los dominios
La clase unifica los principios del diseo modular y la definicin de tipo como de datos que manipulan los
representacin esttica de los datos. La aproximacin de la orientacin a obje- programas.
tos, a diferencia de otras metodologas, mezcla en un nico constructor lings-

tico los conceptos de mdulo y tipo: la clase es la unidad de descomposicin del
software (mdulo), a la vez que define un tipo de dato (en cierta manera, la clase
se puede relacionar con los tipos abstractos de datos).
3.1. Los papeles de la clase y del objeto
A veces, se hace difcil diferenciar los conceptos de clase y objeto. Esto es por-
que, coloquialmente, objeto no tiene un significado unvoco: podemos enten-
der por objeto tanto una entidad nica y diferenciada como un grupo de
entidades con ciertas caractersticas comunes, y slo diferenciamos estas dos
interpretaciones por el contexto.
Cuando hablamos del objeto coche, todo el mundo entiende que nos referimos a un ele-
mento que sirve para transportar personas con un nmero suficiente de ruedas que lo
sostienen y un motor que lo hace avanzar. En este caso, el objeto coche no se refiere a
una nica entidad, sino a un conjunto de entidades con unas caractersticas comunes.
En este caso concreto, coche se debe entender como una clase de objetos, ya que repre-
senta un grupo o conjunto de entidades con ciertas caractersticas comunes.
Cuando hablamos del coche de Jos, nos referimos a un coche concreto, hecho de un ma-
terial concreto con unos colores concretos. En este caso, coche se debe entender como un
objeto o instancia que identifica un miembro individual y concreto de la clase de obje-
tos coche.
Desde el punto de vista de la representacin, se tiene que diferenciar entre la

clase de objetos, que describe un grupo de entidades con caractersticas comu-
nes, y el objeto o instancia, que describe un miembro concreto del grupo.
El objetivo principal de la metodologa de orientacin a objetos es describir la

realidad utilizando objetos. El objeto se debe entender como una representa-
cin o abstraccin de una porcin de la realidad que tiene un significado con-
creto en el problema que se quiere resolver, debe establecer de manera precisa
los umbrales de la realidad representada. Es decir, slo tiene que reflejar los as-
pectos de la realidad que sean relevantes para el problema que se quiere resol-
ver. Decidir cules son estos aspectos constituye una de las etapas esenciales a
la hora de analizar y disear el programa. Esta decisin nos permitir identifi-

car grupos de objetos que comparten semejanzas o caractersticas, lo cual nos
lleva al concepto clase de objetos, que hemos introducido antes.
Es muy importante ver la relacin entre clase y objeto y, sobre todo, la secuen-
cia temporal que lleva del objeto a la clase en la etapa de anlisis y diseo. De
alguna manera, primero es el objeto y despus la clase. Quiz sta es la razn
por la cual hablamos de metodologa de orientacin a objetos y no de orien-
tacin a clases, como algunos autores reivindican.
Ejemplo
Si se nos plantea un problema relacionado con las diferentes categoras de los permisos
de conducir, a la hora de caracterizar los objetos del dominio vehculos de automocin nos
tendremos que fijar en atributos tcnicos como el nmero de ruedas, el peso, la cilindra-
da, si se trata de vehculos articulados, si se destinarn a transportar mercancas o perso-
nas, etc. stos son los aspectos de la realidad que representarn los objetos. As,
hablaremos de vehculos de dos, tres o ms ruedas; de vehculos de hasta 3.500 kg, hasta
16.000 kg o de peso superior, etc. De esta manera, los permisos de conducir establecen
ocho categoras de vehculos relacionadas con los aspectos que hemos destacado.
El permiso A2 permite conducir motocicletas de cualquier cilindrada y automviles de

tres ruedas cuyo peso, en vaco, no exceda los 400 kg. Es decir, cualquier objeto vehculo
con estas caractersticas pertenece al grupo de vehculos que se pueden conducir con un
permiso de tipo A2. O dicho en trminos del concepto de clase, cualquier vehculo per-
teneciente a la clase A2 tiene dos o tres ruedas, su cilindrada no est limitada y su peso
no es superior a 400 kg en vaco. La clase recoge todas las caractersticas comunes a un
grupo de objetos que representan ciertos aspectos de la realidad bien delimitados.
Ahora nos fijaremos en el mismo dominio de la realidad (vehculos de automocin), pero

desde el punto de vista de un problema relacionado con una empresa de alquiler de ve-
hculos. En este caso, hay que pensar en la tarifacin y las condiciones de alquiler segn
el uso del vehculo. As, podramos distinguir entre vehculos de uso industrial (vehculos
de carga) y turismos. Podramos caracterizar los vehculos industriales segn la capacidad de
carga y los turismos segn la calidad del vehculo. De esta manera, hablaramos de vehculos
industriales combi, de carga pequea, mediana, grande (camiones) y de turismos econ-
micos, medios, de lujo, monovolmenes o minibuses si entris en la web de cualquier
empresa de alquiler de vehculos, encontraris una clasificacin muy parecida.
La eleccin de unas caractersticas diferentes para describir las mismas entida-

des de la realidad lleva a un conjunto de diferentes clases de objetos.
El concepto de clase permite un nivel de abstraccin elevado que facilita ana-

lizar y representar los problemas: la clase describe un grupo de objetos que
comparten el conjunto de caractersticas que son de inters en un contexto de-
terminado. Por lo tanto, antes de definir la clase, se tienen que haber definido
los objetos como representaciones de la realidad que delimitan los aspectos de
inters para el problema que hay que resolver.
En el problema del permiso de conducir, es indiferente la marca del vehculo. En el pro-

blema de la empresa de alquiler, en cambio, la marca del vehculo s que es relevante,
pero el peso no.
As, podramos decir que el concepto de clase tiene dos vertientes: una vertien-
te semntica y otra que podramos denominar operacional:
La vertiente semntica permite relacionar fcilmente la estructura clase

con los grupos de entidades de la realidad representada. Esto siempre faci-
litar la comprensin del problema ya que, de acuerdo con la regla de ma-

peo directo, las clases normalmente representan grupos de entidades que
pertenecen a la realidad en el problema tratado.
La vertiente operacional permite relacionar la estructura clase con los as-

pectos funcionales de la realidad representada delimitados en la etapa de
anlisis del problema. Es decir, en la definicin de la clase, se establecen
perfectamente qu caractersticas y funcionalidades se han representado.
Como ya hemos comentado anteriormente, cuando se trabaja con la metodo-

Antes de continuar, es importante
que comprobis que diferenciis
loga de la orientacin a objetos, durante las etapas de anlisis y diseo de una correctamente los conceptos de clase
(clase de objetos) y objeto (instancia
aplicacin, se identifican los objetos o entidades del mundo real, junto con sus de la clase).
caractersticas de inters para el problema tratado, que llevan a definir las cla-
ses. Una vez definidas las clases, ya podemos hablar de un objeto o instancia
de una clase como un individuo que existe y que tiene sentido en un momen-
to y un contexto determinados. La figura siguiente ilustra estos conceptos:
Figura 3. Clase y objeto
En la clase Person, estn representadas las propiedades que caracterizan a una persona
(entidad del mundo real), mientras que los diferentes objetos representan a individuos
concretos.
3.2. La clase como estructura esttica
Dado que el objeto focaliza la metodologa de la orientacin a objetos, parece

Hasta ahora...
pertinente que nos preguntemos por qu hay que hablar de las clases. La exis-
... nos hemos referido a las cla-
tencia de las clases facilita describir los problemas mediante un proceso de abs- ses como una estructura en la
traccin: con la clase, se caracterizan y representan de una vez y para siempre que se representan las propie-
dades y funcionalidades que
las propiedades y funcionalidades de un conjunto de objetos de la realidad de caracterizan a un conjunto de
objetos en un contexto deter-
acuerdo con los umbrales definidos por el problema abordado. minado, delimitado por el pro-
blema que se quiere abordar.
Una consecuencia importante de usar clases es que se puede reutilizar el cdi-
go que las define para todos los objetos (sus instancias) que haya en un mo-
mento determinado. Un objeto siempre sabe a qu clase pertenece, es decir,
conoce sus propiedades y funcionalidades, ya que se han descrito en la clase a
la que pertenece. Dicho de otra manera, se reutiliza el cdigo definido en la
clase para cada objeto que hay en un momento determinado durante la ejecu-
cin del programa.
Relacin clase-objeto
Cuando hablamos de objeto, hacemos referencia a una estructura que
Muchos lenguajes de progra-
hay en un momento determinado de la ejecucin del programa, mien- macin permiten averiguar a
tras que cuando hablamos de clase hacemos referencia a una estructura qu clase pertenece un objeto
en tiempo de ejecucin.
que representa a un conjunto de objetos.
Por este motivo, podemos considerar la clase como una estructura esttica,
mientras que el objeto se considera como una estructura dinmica, vistas las
connotaciones temporales de su existencia.
Como hemos comentado, la vertiente operacional de la clase establece las carac-

tersticas y funcionalidades de la realidad que se tienen que representar, y esta
representacin se articula en dos tipos de elementos: los atributos de la clase (el
estado de sus objetos) y sus mtodos u operaciones (su comportamiento).
Por convencin, a la hora de llamar una clase utilizaremos un texto lo ms ex-

plcito posible que empiece siempre con mayscula (por ejemplo, Persona,
Alumno). En caso de utilizar construcciones nominales, irn con mayscula
las iniciales de cada palabra (por ejemplo, AlumnoUniversitario).
3.2.1. Atributos
Un atributo es una caracterstica o propiedad de la entidad representa-

da por la clase. Un atributo siempre toma valores y define su tipo, que
puede ser tanto un dato como una estructura de datos: un vector, una
lista, etc.
Los tipos de datos que puede tener un atributo se corresponden con los consi-
derados convencionalmente como bsicos (enteros, reales, caracteres, etc.) o
con objetos de alguna clase, que puede ser la misma en la que se define el atri-
buto u otra.
Si un atributo de una clase define como tipo de datos un objeto (de otra clase
Esta cuestin...
o de la misma), normalmente indica algn tipo de relacin de asociacin entre
... es de gran importancia en la
las clases implicadas. modelizacin de la realidad
descrita en el problema trata-
do. Lo veremos ms adelante.
Una clase puede tener cualquier nmero de atributos, o incluso puede no te-
ner ninguno.
Ejemplo
Consideremos una primera aproximacin a la caracterizacin del individuo persona, la

clase Person que hemos ilustrado en la figura 3.
En esta primera aproximacin, definimos los atributos name (nombre) y birthDate

(FechaNacimiento) con el fin de caracterizar a los individuos (objetos) pertenecientes a la
clase PersonPersona): el atributo name se define como tipo cadena de caracteres (String)
y el atributo birthDate, como un objeto de tipo Date (representacin de una fecha).
La figura 4 muestra la clase Person, con los atributos mencionados, junto con tres obje-
tos en los cuales los atributos toman los valores que identifican a cada uno de los indivi- Los elementos
diferenciadores...
duos representados:
... entre los objetos o instancias
de una misma clase son los va-
lores concretos que toman los
atributos en cada objeto.
Figura 4. Clase, atributos y objetos

Para los atributos tambin utilizaremos un texto que sea ilustrativo, que tiene
que empezar en minscula (por ejemplo, name) y, en caso de utilizar construc-
ciones nominales, irn con mayscula las iniciales de las palabras intermedias
(por ejemplo, birthDate).
3.2.2. Mtodos u operaciones
Un mtodo es la implementacin de un servicio que puede ser requerido

por cualquier objeto de la clase. El mtodo muestra, o define, parte del
comportamiento de los objetos representados en la clase. Se puede definir
un mtodo como una abstraccin de parte del comportamiento de la
entidad del mundo real representada en la clase.
Una clase puede tener cualquier nmero no nulo de mtodos. El hecho de ser
no nulo es porque una clase siempre tiene, como mnimo, un mtodo especial
denominado constructor. Este mtodo se ejecuta cada vez que se crea un objeto
durante la ejecucin del programa y, bsicamente, se encarga de asignar la me-
moria necesaria para soportar toda la informacin asociada al objeto e inicia-
lizar variables, entre otras tareas de inicializacin.
Como notacin utilizaremos un texto, normalmente un verbo o una expresin

verbal que ilustre el comportamiento del mtodo, que empiece con minscula,
y en caso de ser una construccin verbal, irn con mayscula las iniciales de las
palabras intermedias (por ejemplo, asignarValorNombre).
Adems de por el nombre, un mtodo se caracteriza por los argumentos o pa-

Para ver el formato de las firmas
rmetros de entrada que recibe y por el valor de retorno que resulta de ejecutar de los mtodos, podis consultar el
mdulo El lenguaje de programacin
Java.
el comportamiento que implementa. En este sentido, y slo en este sentido,
se puede establecer una relacin entre los mtodos de un objeto y las funcio-
nes y procedimientos de los paradigmas clsicos de programacin. La descrip-
cin de estos elementos se conoce como la firma del mtodo.
methodName(Param1Type param1..., ParamNType paramN):ReturnType
Normalmente se distinguen dos tipos de mtodos; los que afectan a los valo-
res de los atributos del objeto y que, por lo tanto, pueden tener efectos colate-
rales (cambian el estado) sobre el mismo objeto o sobre otros, y los que
simplemente calculan ciertos valores y despus son retornados sin afectar a El nombre dado...
ningn otro objeto:
... a mtodos que asignan va-
lor a un atributo acostumbra a
construirse con el verbo ingls
1) Un ejemplo tpico del primer tipo es el conjunto de mtodos accesores de- set (asignar) seguido del
nombre del atributo.
finidos para asignar valores a los atributos del objeto, tambin conocidos
como mtodos accesores de escritura. En la clase Person (Persona) del ejemplo

El uso de mtodos
anterior, tendramos que declarar dos mtodos accesores [uno para name accesores...
(nombre) y el otro para birthDate (fechaNacimiento)], que tendran ... no es slo una cuestin de
como nombres setName y setBirthDate, con los parmetros correspon- estilo (que ya es importante),
sino que tiene implicaciones a
dientes a cada caso. la hora de realizar el manteni-
miento de las clases en amplia-
ciones futuras de las
aplicaciones.
Es muy importante asignar los valores de los atributos de un objeto siempre
por medio de los mtodos accesores correspondientes, ya que permiten mo-
dificar la estructura interna de la clase sin modificar las interfaces de comu-
nicacin con las otras clases y, por lo tanto, no habr que modificarlas
cuando se realicen cambios que slo afecten a la estructura interna. De esta
manera, podemos mantener el principio de encapsulamiento y ocultacin.
2) Si hablamos del segundo tipo de mtodos, tenemos que hablar de los m-

El nombre dado...
todos accesores de lectura, que simplemente devuelven el valor de un atributo
... a los mtodos que leen el
del objeto. Se pueden argumentar las mismas razones para utilizar los acceso- valor de un atributo acostum-
res de lectura que hemos utilizado para justificar los accesores como escritura. bra a construirse con el verbo
ingls get (tomar) seguido del
En la clase Person del ejemplo anterior, tendramos que definir un par de m- nombre del atributo.
todos accesores de lectura que seran getName y getBirthDate, que nos re-
tornaran los valores de los atributos consultados.
Tambin podemos considerar entre este tipo de mtodos los que elaboran in-
formacin a partir de los atributos declarados en la clase; por ejemplo, dada la
clase Persona, podemos tener un mtodo que nos d la edad del objeto repre-
sentado a partir de un clculo sobre su fecha de nacimiento.
Este tipo de mtodo recibe el nombre de atributo derivado, ya que se puede

construir informacin nueva sobre el objeto a partir de los atributos declara-
dos explcitamente.
3.2.3. Visibilidad de los atributos y mtodos
Hasta el momento, sabemos que una clase puede tener un nmero indetermi-
nado de atributos y mtodos y que es conveniente que la clase oculte toda la
informacin que no es relevante para su uso para que se favorezca la modula-
ridad (ocultacin de la informacin).
Recordemos que, cuanta menos informacin pblica tiene una clase es decir,
cuanto menor es la parte visible de la clase por las otras clases que pueden in-
teractuar, menos probable es que se propaguen las modificaciones que se rea-
lizan sobre sta.
Si seguimos estas reglas de diseo, contribuimos, como ya hemos comentado,

a incrementar factores de calidad como la reusabilidad, la portabilidad y la fa-
cilidad de uso de las clases.
Cuando hablamos de visibilidad de un atributo o de un mtodo, lo debemos

entender en relacin con las otras clases ajenas a la que los define. Un objeto
siempre puede acceder a cualquier atributo o mtodo de la clase a la cual per-
tenece y lo puede utilizar sin ningn tipo de restriccin. Para poder establecer
claramente la visibilidad de los atributos y mtodos, los lenguajes de progra-
macin definen tres niveles de acceso distintos.
Pblico: cualquier clase puede acceder y utilizar cualquier atributo o m-

todo declarado como pblico.
Protegido: cualquier clase heredera puede acceder a cualquier atributo o El concepto de herencia lo veremos
en mdulos posteriores.
mtodo declarado como protegido en la clase padre y utilizarlo.
Privado: ninguna clase puede acceder a un atributo o mtodo declarado

como privado ni utilizarlo.
3.2.4. La clase como estructura modular
Antes de continuar profundizando en otros conceptos bsicos que caracteri-

zan la metodologa de orientacin a objetos, es conveniente hacer una re-
flexin sobre el principio de modularidad que tiene que guiar la definicin de
las clases.
La clase en s misma no es una estructura modular
Si llevamos esta cuestin al absurdo, podramos codificar una aplicacin entera como
una nica clase: los atributos haran el papel de las variables globales y los mtodos el
papel de las funciones y procedimientos de una estructuracin funcional. Cada mtodo
tendra las variables locales y, adems, la posibilidad de acceder a todos los atributos (re-
cordad las reglas de visibilidad). Slo hara falta un mtodo que iniciara la ejecucin (pa-
pel del programa principal) para tener una clase que codificara un programa diseado
con el enfoque procedimental.
Obviamente, aunque se haya utilizado una clase, una aplicacin como la descrita ante-
riormente no responde a ninguna de las caractersticas de la orientacin a objetos.
Para conseguir que las clases tengan una estructura modular, a la hora de di-
searlas se deben tener en cuenta los criterios y las reglas de calidad que ya co-
nocemos y que resumimos a continuacin:
Hay que identificar para cada clase, de la manera ms evidente posible, las
entidades de la realidad representadas. De esta manera, cumpliremos la re-
gla del mapeo directo intentando seguir los criterios de descomposicin/
composicin, comprensin y continuidad modular.
Los atributos de una clase siempre deben tener una visibilidad no pblica.
El acceso de los otros objetos a los atributos se har estrictamente mediante
los mtodos accesores y los mtodos definidos como atributos derivados.
Esto no quiere decir que cualquier mtodo, accesor o no, tenga que ser p-
blico: slo se definirn como pblicos los estrictamente necesarios. Con es-
to, cumpliremos la regla de ocultacin de la informacin.
Seguir correctamente estos preceptos de diseo no es una cuestin que se pue-

da aprender slo leyendo este texto. Es una cuestin que depende de la habi-
lidad y, sobre todo, de la experiencia del programador.
3.2.5. Representacin de una clase con UML
Una de las caractersticas ms interesantes de la orientacin a objetos es

que se trata de una metodologa de diseo aplicable a muchos dominios.
Esto ha provocado que haya muchos desarrollos orientados a definir un
lenguaje o formalismo que facilite la modelizacin de problemas para po-
der tratarlos con esta metodologa, independientemente del dominio del
problema.
Uno de estos desarrollos es el UML, que permite describir y construir mo-

UML es la sigla de
delos que representan sistemas basndose en los conceptos de la orienta- Unified Modeling Language.
cin a objetos con unas caractersticas de representacin grficas que hacen

relativamente sencillo describir y entender un diseo orientado a objetos. A
partir de ahora, utilizaremos este lenguaje para definir formalmente nues-
tras clases.
Las clases se representan con una tabla dividida en tres reas: en el tercio su-
perior, se declara el nombre de la clase; en el central, se enumeran los atribu-
tos, y en el tercio inferior, los mtodos:
Figura 5. Representacin de una clase con UML
Los atributos especifican el tipo de dato o de objeto que almacenarn, y los

mtodos se especifican con su firma.
Para indicar la visibilidad de los atributos y los mtodos, se pueden utilizar los
smbolos siguientes:
+ : pblico
# : protegido
: privado
De acuerdo con esta nomenclatura, la representacin de la clase Person en

UML podra quedar de la manera siguiente:
Figura 6. Representacin de la clase Person con UML
Con vistas a implementar el diseo (codificacin de las clases), el diagrama

UML acostumbra a acompaarse con una descripcin detallada del significado
de los atributos y de la manera en la que cada mtodo realiza las tareas para
las cuales ha sido declarado.
Utilizar un lenguaje de modelizacin como el UML permite leer y entender lo

que representa una clase sin que sea necesario ver el cdigo.
3.3. El objeto como estructura dinmica
Ahora estudiaremos el objeto como instancia de una clase que existe durante
la ejecucin del programa.
Recordemos que, a partir de lo que hemos estudiado hasta ahora, pode-

mos definir una clase como una estructura de representacin de un
conjunto de entidades de la realidad que tienen ciertas caractersticas y
funcionalidades comunes al dominio del problema abordado. De he-
cho, podemos entender una clase como uno de los elementos que in-
tervienen en la construccin del modelo que representa la realidad
dentro de los umbrales establecidos por un problema.
Si bien la clase describe las entidades de la realidad modelizada, no puede re-

presentar su evolucin en el tiempo durante la ejecucin del programa (recor-
dad el concepto de clase como estructura esttica). Este papel est reservado al
objeto o instancia de la clase.
El objeto representa una entidad concreta de la realidad representada,

determinada por el conjunto de valores que toman los atributos defini-
dos para la clase a la que pertenece el objeto y que, habitualmente, sern
diferentes de un objeto a otro.
Normalmente, un objeto evoluciona en el tiempo desde que se crea: el valor

de sus atributos puede variar al mismo tiempo que avanza la ejecucin del pro-
grama. Esta dependencia temporal nos permite considerar el objeto como una
estructura de representacin dinmica de una entidad concreta de la realidad.
Podemos definir el estado de un objeto como el conjunto de valores de los

atributos y el conjunto de mtodos activos en un instante de tiempo determi-
nado (siempre durante la ejecucin del programa). El conjunto de estados de
todos los objetos que hay en un momento determinado define el estado del
programa en s mismo.
Durante la ejecucin del programa, un objeto se crea cuando se necesita, y se La sintaxis para crear objetos puede
variar ligeramente de un lenguaje a
otro. Podis ver el mdulo El lenguaje
tiene que eliminar cuando ya no es til. de programacin Java.
Una vez creado el objeto, podemos acceder a sus atributos y mtodos, siempre
que la visibilidad definida en la clase lo permita. En orientacin a objetos, la
demanda de ejecucin de un mtodo se suele entender como un proceso co-
municativo en el que un objeto A pide a un objeto B que realice un servicio
determinado.
Por ejemplo, para acceder al atributo birthDate de un objeto Juan de la cla-

se Person, lo podemos hacer de distintas maneras:
Desde dentro de la clase (sin las restricciones de visibilidad):
Date d = birthDate;
O bien
Date d = getBirthDate();
Dependiendo de si accedemos directamente al atributo almacenado o a la ope-

racin consultora. Es aconsejable utilizar la operacin consultora en vez del
acceso directo al atributo.
Para acceder desde fuera de la clase, lo que necesitamos es el nombre del

objeto es decir, una variable de este tipo de objeto e invocar el mtodo o
acceder al atributo. Slo podemos acceder a los atributos cuyos permisos ten-
gamos, segn su visibilidad.
juan.setBirthDate(23/04/1980);
...
int e = juan.getAge();
Si intentamos acceder directamente a los atributos desde fuera de la clase y

este acceso viola la visibilidad definida para la clase, el compilador tiene que
generar un error que indique este problema.
En este apartado, hemos hablado de objeto vivo en el sentido de que existe slo durante
la ejecucin de un programa. De hecho, esta expresin es redundante, ya que un objeto
se crea cuando se necesita y slo existe mientras es til. Es decir, un objeto siempre est
vivo, si no, simplemente no existe: cuando un objeto deja de ser til, se tiene que elimi-
nar. La manera de eliminar un objeto depende del lenguaje. En algunos lenguajes como
C++, esta tarea la tiene que realizar el programador; en cambio, en otros como Java, esta
tarea la lleva a cabo el mismo sistema (la mquina virtual Java).
3.4. Extensin de los atributos y de los mtodos de una clase
Una clase est constituida por dos tipos de elementos, los atributos y los m-
todos, que caracterizan los objetos creados como instancia de la clase. Hasta
ahora, hemos visto que los atributos y los mtodos definidos en una clase son
replicados en todas las instancias de sta, pero esto no tiene por qu ser siem-
pre as: nos puede interesar que un atributo o mtodo determinado sea comn
y nico para todos los objetos de una clase.
La metodologa de orientacin a objetos tiene en cuenta esta necesidad e in-

troduce el concepto de extensin de un atributo o mtodo.
La extensin de un elemento de una clase (atributo o mtodo) especi-

fica si aparece en cada objeto creado o si slo aparece una vez para todos
los objetos creados.
En muchos lenguajes de programacin, se definen dos niveles de extensin:

alcance de instancia y alcance de clase. Esta caracterstica hace que podamos
hablar de atributos de instancia o atributos de clase y de mtodos de instancia o
mtodos de clase.
La gran mayora de los atributos y mtodos sern de instancia, ya que cada

objeto conserva el estado de manera independiente a la de los otros. Aun as,
a veces ser necesario que tengamos algunos atributos o mtodos que nos den
algn tipo de informacin genrica o comn a todos los objetos instanciados
hasta aquel momento dentro del programa, o que no tiene sentido almacenar-
la en un objeto especfico. Un ejemplo podra ser un contador del nmero de
instancias que se han creado hasta el momento, y como mtodo de clase, uno
que nos permita saber el nmero de instacias creadas.
Si en el ejemplo anterior de la clase Person quisiramos contar el nmero de objetos que

se hubiesen instanciado, necesitaramos un atributo de clase que nos sirviera para alma-
cenar este dato y un par de mtodos para modificar su valor.
Para representar los atributos o mtodos con alcance de clase en UML, su-
brayaremos el elemento. Si aadimos un contador de instancias de la clase
Person y un par de mtodos para incrementar y disminuir este contador,

la clase ser as:
Figura 7. Representacin de la clase Person con atributos

y mtodos de clase
Los mtodos accesores se han definido como mtodos de clase pero, puesto que son pri-
Dependiendo del lenguaje de
vados, hay que prestar atencin ya que puede ser que en algunos casos, aunque sean m- programacin, la definicin de
atributos y mtodos de clase se realiza
todos accesores a atributos de clase, stos tengan que ser definidos como mtodos de de manera diferente. Podis ver el
mdulo El lenguaje de programacin
instancia. Ms adelante, veremos cmo se puede hacer una llamada a un mtodo de clase Java.
sin que haya ningn objeto de sta.
Figura 8. Representacin de objetos de la clase Person
Otra utilidad para los mtodos de clase es la definicin de operaciones de uti-

lidad, es decir, operaciones que toman una entrada y devuelven una salida que
se produce exclusivamente a partir de los parmetros de entrada, sin tener en
cuenta el estado del objeto. Este mecanismo sera el mismo que se hace en pro-
gramacin procedimental con las bibliotecas de funciones.
3.4.1. Los mtodos constructor y destructor de una clase
Los mtodos constructores son unos mtodos de clase especiales que

nos sirven para crear un objeto nuevo. Es comn que los lenguajes de
programacin incluyan un mtodo constructor por defecto, y tambin
que permitan que el programador defina mtodos propios que realicen
las tareas necesarias para inicializar el objeto creado.
Aunque en general no es obligatorio que el programador defina los mtodos

constructores, en la prctica se hace habitualmente dado que, entre otros mo-
tivos, de esta manera se asegura que los atributos se inicialicen con los valores
correctos.
Cada lenguaje puede tener algunas restricciones sobre los aspectos siguientes:
La forma de los constructores

Para ver las restricciones que ofrece
La declaracin de los constructores el lenguaje que utilizaremos, podis
ver el mdulo El lenguaje de
programacin Java.
La responsabilidad del programador en la reserva de memoria
La responsabilidad del programador en la inicializacin de los atributos
La posibilidad de que haya ms de un constructor
Los nombres de los constructores
Independientemente de quin se encarga de eliminar los objetos, habitual-

Recordad
mente se tendrn que realizar ciertas operaciones antes de que el objeto deje
En Java la eliminacin de obje-
de existir. tos es responsabilidad de la
mquina virtual Java, mientras
que en C++ la tarea recae en el
programador.
Los mtodos que realizan las tareas previas a la eliminacin del objeto
se suelen denominar destructores. Una clase puede definir un nico
mtodo destructor cuando, adems de liberar la memoria ocupada por
el objeto que se elimina, sea necesario especificar la ejecucin de alguna
operacin.
Ms adelante, veremos mucho ms detalladamente estos mtodos.
3.5. Sobrecarga
La sobrecarga es la capacidad de poder asociar ms de un significado a

un mismo identificador que aparece dentro de un programa.
No todos los lenguajes permiten la sobrecarga es decir, no podemos tener dos Algunos lenguajes que no permiten
la sobrecarga son C, Fortran, etc.
elementos con el mismo identificador. En este caso, lo que podemos hacer es
nombrar los elementos de manera muy parecida para expresar que realizan ta-
reas parecidas.
Aunque para nosotros los mtodos sobrecargados tienen el mismo nombre, lo

que hacen los lenguajes que permiten la sobrecarga es aadir un sufijo al nom-
bre del mtodo que indica, con una codificacin especial, el nmero, tipo y
orden de los parmetros para que se pueda invocar el mtodo correcto en cada
caso.
Se puede producir sobrecarga en los nombres de las variables (distinguibles por

Veremos la sobrecarga en el
sus tipos), en los nombres de los mtodos (diferenciables por los parmetros, mdulo El lenguaje de
programacin Java.
tanto por el nmero como por el tipo) y en los operadores (dependiendo de los
tipos de datos a los que afectan). Es el compilador el que decide a cul de
los atributos, mtodos u operadores nos referimos.
El tipo de sobrecarga ms comn es la sobrecarga de mtodos, que se puede

dar en una misma clase (dos o ms mtodos de la misma clase con el mismo
nombre, pero con parmetros diferentes).
La sobrecarga es un mecanismo muy til para la programacin: permite

que un mtodo (varios mtodos con el mismo nombre) haga cosas di-
ferentes segn el nmero y el tipo de los parmetros que recibe.
3.6. Otros aspectos sobre los lenguajes de programacin

orientada a objetos
A la hora de codificar una aplicacin diseada con la metodologa de orienta-

cin a objetos, se tiene que distinguir habitualmente entre dos tipos de len-
guajes orientados a objetos:
Lenguajes puros: todos los mdulos de un programa tienen que ser clases. Ejemplos: Java, Smalltalk o Eiffel.
En los lenguajes puros, cualquier definicin (de datos o de cdigo) se tiene que basar en
una clase. Es decir, no existen los conceptos de rutina, funcin o procedimiento y tam-
poco el de programa principal. Slo hay clases, con los mtodos y atributos correspon-
dientes.
Lenguajes hbridos: permiten utilizar clases y objetos que se pueden com- Ejemplos: C++, Delphi
o Object COBOL.
binar con estructuras procedimentales clsicas.
El proceso con el que empieza la ejecucin vara segn el lenguaje. Todos los
lenguajes puros tienen mecanismos que permiten decir al compilador que hay
una clase que es la principal y el mtodo de la clase por la cual debe empezar
la ejecucin del programa.
Resumen
En este mdulo, hemos visto distintos aspectos relacionados con el desarrollo

de aplicaciones informticas.
En el apartado Criterios de calidad, hemos presentado una serie de factores

que permiten evaluar la calidad del cdigo de la aplicacin y que, por lo tanto,
tendran que presidir todo desarrollo.
En el apartado El principio de modularidad, hemos presentado el acerca-

miento modular como una metodologa que facilita la consecucin de un
buen nivel de calidad en el cdigo. Hay que tener presente que la metodologa
de orientacin a objetos es, en esencia, un acercamiento modular.
Finalmente, en el apartado Clases y objetos hemos introducido los mecanis-

mos de representacin bsicos que proporciona la orientacin a objetos.
Antes de profundizar en otros aspectos de la metodologa de la orientacin a

objetos, es necesario que os aseguris de haber alcanzado los conceptos si-
guientes para poder seguir sin dificultad los prximos mdulos:
Concepto de clase en el diseo de una aplicacin orientada a objetos.
Definicin de una clase: atributos y mtodos, y visibilidad de stos.
Concepto del objeto como elemento dinmico en una aplicacin orienta-

da a objetos.
Creacin de objetos: mtodos constructores, estado del objeto, mtodos

destructores.
Ejercicios de autoevaluacin
1. Qu factores de calidad destacarais a la hora de disear una aplicacin?
2. Qu entendis por mapeo directo?
3. Enumerad los tipos de mtodos que hemos explicado en este mdulo y haced una peque-
a descripcin de los mismos.
4. Creis que es viable tener un mtodo accesor de lectura con visibilidad privada? Y uno
con visibilidad protegida?
5. Creis que tiene sentido que todos los mtodos accesores de escritura tengan visibilidad
pblica?
6. Qu diferencia hay entre las responsabilidades de clase y las de instancia?
7. Poned un ejemplo de responsabilidades de clase, diferente de los constructores y destruc-

tores, para una clase Vehiculo.
8. Por qu motivo el constructor debe ser un mtodo con responsabilidad de clase y no lo

puede ser con responsabilidad de instancia?
Solucionario
1. En realidad, tendran que estar presentes todos los factores de calidad, pero quiz en la eta-
pa de diseo los que hay que tener ms presentes son la escalabilidad de la aplicacin y la
facilidad de reutilizacin de las estructuras. El primero porque, normalmente, las aplica-
ciones deben crecer con el tiempo y el segundo porque, tanto para el posible crecimiento
de la aplicacin como para desarrollar otras aplicaciones, una buena capacidad de reutili-
zacin de las clases es muy til.
2. El mapeo directo se tiene que entender como la facilidad para identificar la estructura de
representacin de la realidad modelizada en el contexto del problema que se tiene que re-
solver. Normalmente, seguir esta regla ayudar a hacer un buen diseo modular, ya que la
misma estructura del problema da una visin de cul tiene que ser la estructura de la so-
lucin.
3. En este mdulo, hemos hablado de los tipos de mtodos siguientes:
Mtodos constructores: permiten crear instancias de la clase.

Mtodos accesores de escritura: permiten modificar el valor de los atributos de la clase.
Mtodos accesores de lectura y atributos derivados: retornan el valor de un atributo y per-
miten resolver algn clculo o proceso basndose en los valores de los atributos y en los
argumentos del mtodo.
Mtodos de clase: permiten hacer algn proceso o clculo relacionado con la clase, pero
sin que sea necesario tener una instancia de la clase.
4. Los mtodos accesores de lectura (los que pueden consultar el valor de los atributos de la
clase) normalmente se utilizan para dar acceso a los otros objetos, y por esto suelen ser
mtodos pblicos que forman parte de la interfaz de la clase. De todos modos, puede tener
sentido restringir la visibilidad de un accesor de lectura cuando no se quiere que un atri-
buto sea visible por las otras clases. Los mtodos accesores que tienen visibilidad protegida
pueden tener sentido si tenemos herencia entre clases, pero este concepto lo veremos ms
adelante. Recordad que, para cuestiones de calidad, siempre se tendra que acceder a los
atributos por medio de mtodos accesores.
5. La respuesta debe ser rotundamente no. Observad que sera un contrasentido definir como
privados o protegidos todos los atributos (costumbre ms que recomendable) y despus
definir como pblicos todos los accesores de escritura correspondientes. Slo se tendr que
dar visibilidad pblica a aquellos accesores de escritura que tengan que ser necesariamente
visibles por otras clases, siempre que se pueda asegurar que su posible uso externo no com-
prometer el buen funcionamiento de la aplicacin.
6. Las responsabilidades de instancia (tanto si son atributos como si son mtodos) son aque-
llas que se piden a los objetos de una clase, tanto si es de recordar cosas como de hacerlas.
En el caso de las responsabilidades de clase, es la clase y no sus instancias la que alma-
cena datos o realiza los procesos o clculos.
7. Unos contadores del nmero de instancias creadas, destruidas, etc.
8. Puesto que el constructor nos sirve para crear una instancia de un objeto, no lo podemos
definir como instancia ya que, inicialmente, no tenemos ninguno y, por lo tanto, no po-
demos crear ninguno. Aparte, los mtodos de instancia sirven para modificar el estado de
la instancia, y el propsito del mtodo constructor no es ste.
Bibliografa
Booch, G.; Jacobson, I.; Rumbaugh, J. (1999). El lenguaje de modelado unificado UML. Ma-
drid: Addison-Wesley Iberoamericana.
Joyanes, L. (1998). Programacin orientada a objetos. Madrid: McGraw-Hill.
Meyer, B. (1997). Object-oriented software construction. Santa Brbara: Prentice Hall.
Rumbaugh, J.; Blaha, M.; Premernali, W.; Eddy, F.; Lorensen, W. (1996). Modelado
y diseo orientado a objetos. Madrid: Prentice Hall.

Pid 00161675

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pid 00161675

Uploaded by

Copyright:

Available Formats

Clases y objetos

Jordi Brnquez Jimnez

1. Criterios de calidad .......................................................................... 7

2. El principio de modularidad ......................................................... 21

3. Clases y objetos .................................................................................. 21

3.4. Extensin de los atributos y de los mtodos de una clase ............. 31

Ejercicios de autoevaluacin ............................................................... 37

Una de las diferencias principales de los proyectos informticos respecto de los

La aproximacin clsica al diseo y la implementacin de proyectos inform-

Algunos de los aspectos que han puesto de manifiesto las limitaciones de la

En los apartados 1 y 2 de este mdulo didctico presentamos los criterios de

Los materiales didcticos de este mdulo proporcionan los conocimientos

1. Conocer el conjunto de criterios y reglas que se tendran que cumplir en la

2. Aproximarse al concepto de modelo de la realidad definida por el problema

3. Conocer los mecanismos de representacin en los que se basa la orienta-

En general, se puede decir que, cuando se aprende a programar, los primeros

La tcnica de programacin que hace que el programa principal opere directa-

Una consecuencia muy extendida de la programacin no estructurada es que

La programacin procedimental ofrece una tcnica para extraer las secuencias

Este paradigma permite codificar diferentes funcionalidades en los programas

Una buena estructuracin en el rbol de llamadas facilita mucho la tarea de

La programacin procedimental facilita considerablemente la tarea de codifi-

go, pero no facilita en absoluto la reutilizacin, ya que para implementaciones

La programacin modular facilita la reutilizacin, ya que permite agrupar los

Como hemos presentado ya en el mdulo anterior, la programacin clsica en-

En los dos apartados siguientes, presentaremos de manera resumida los prin-

1.1. Factores de calidad internos

Trataremos con ms profundidad los factores de calidad internos en el aparta-

1.2. Factores de calidad externos

1.2.1. Reutilizacin de cdigo

El hecho de que aplicaciones informticas diferentes presenten patrones pare-

Podemos medir la reutilizacin del cdigo a partir de la capacidad de utilizar

El concepto de reutilizacin es uno de los factores principales de calidad que

1.2.2. Escalabilidad de la aplicacin

Entendemos por escalabilidad de una aplicacin la facilidad con la que

Ciertas metodologas clsicas de ingeniera del software consideraban que un

Dado que las aplicaciones normalmente no son problemas cerrados, aparecie-

La ampliacin de las funcionalidades de un programa pequeo, en general, no

Para mejorar la escalabilidad de una aplicacin informtica, hay dos princi-

La orientacin a objetos ayuda

Descentralizacin. Cuanto ms autnomos sean los mdulos, ms probable

1.2.3. Portabilidad del cdigo

Podemos definir la portabilidad del cdigo como la facilidad de uti-

La mayor parte de las incompatibilidades entre plataformas no responden a

Figura 1. Esquema de aplicacin para favorecer la portabilidad

Definimos la usabilidad como la facilidad con la que personas de or-

Aunque no es indispensable, la usabilidad ayuda al hecho de que los usuarios

La manera en la que se disean los programas puede facilitar la tarea de apren-

La funcionalidad de una aplicacin es la facilidad que tiene para am-

Es importante reconocer y aceptar que, a diferencia de otros campos de la inge-

Incorporar funcionalidades nuevas puede hacer ms difcil localizar las

Incrementar funcionalidades acostumbra a incluir tambin que se reestruc-

1.3. Otros factores de calidad

Podemos definir la precisin como la capacidad de un programa de rea-

Aunque puede parecer que la precisin se puede conseguir fcilmente, en reali-

Los mtodos para garantizar precisin suelen ser condicionales y se basan en

En la figura 2, ilustramos el concepto de aproximacin multinivel. Podis ob-

Figura 2. Aproximacin multinivel de una aplicacin

Un programa es robusto cuando reacciona apropiadamente a condicio-

Si definimos la precisin respecto de las condiciones de operacin recogidas

Aunque la robustez es un concepto ms difuso, hay que tenerlo en cuenta en

La compatibilidad en programacin es la facilidad con la que se pue-

La importancia de la compatibilidad reside en el hecho de que los elementos de