Resúmenes POO Rigago PDF

!!!
TEMA 1: OBJETOS Y CLASES

"
los objetos Java modelan los objetos pertenecientes a u n dominio d e problema.
'
los objetos s e crean a partir d e clases → l a clase describe e l tipo d e objeto.
↳ Los objetos representan las instanciaciones individuales d e la clase.
°
Nos referimos a cada objeto particular con el nombre de instancia.
•
BlueJ →
E l á r e a de l a parte inferior d e l a pantalla en l a que s e muestran los objetos
creados s e llama banco d e objetos(object bench).

• Podemos comunicarnos c o n los objetos invocando métodos sobre los mismos.
S i invocamos u n método, los objetos normalmente llevan a cabo u n a acción.

'
los métodos pueden tener parámetros para proporcionar información adicional para una
tarea. ↳ Pa r a cada parámetro s e define u n tipo y u n nombre.

°
A l a cabecera d e un método se l e denomina signatura,→ Proporciona l a información necesaria
/ para invocar dicho método.

Consta d e l nombre d e un método y los tipos d e parámetros presentes e n s u cabecera.
°
Los parámetros tienen tipos → El tipo define l a clase de valores que puede tomar u n
parámetro.
°
Comentarios → Por encima de l a cabecera del método.
↳ s e incluyen proporcionar información para e l lector (humano) del programa.
para
°
Instancias múltiples → Pueden crearse varios objetos similares a partir d e una única
clase.
°
los objetos tienen u n estado → se representa almacenando valores en campos.
•
Blue]→ E l estado de u n objeto puede inspeccionarse seleccionando l a función Inspecte n el
menú emergente del objeto. → Inspectord e objetos (object inspector).
t
Es una vista ampliada d e l objeto,e n l a q u e s e muestran los
campos almacena dos

dentro del mismo.
Resúmenes POO Rigago 1 de 74

' To d o s l o s objetos de l a m i s m a clase tienen los m i s m o s
campos.]
E l número, los tipos y losnombres d e los campos se definen
dentro d e una clase, n o en u n objeto.
.
Lo s valores d e los campos se almacenarán en e l objeto.
°
Los métodos se definen e n l a clase del objeto → dos los objetos d e u n a m i s m a clase
tendrán los mismos métodos.

^
l o s métodos s e invocan sobre objetos concretos.
•
BlueJ → show Terminal (Mostrar Terminal)e n e l menú View(Uer).
|
seleccionar Record method calls (Registrar llamadasa métodos) e n e l menú
Options (Opciones)
¢
Esto hará que todas nuestras llamadas a métodos
s e escriban e n e l terminal.
SÁN Code Pad (Mostrar
teclado de código) e n e l menú View.
↳ Pueden recuperarse comandos utilizados anteriormente en e l Code Pa d
utilizando l a tecla flecha hacia arriba.
Invocación d e métodos → l o s objetos pueden comunicarse entre s í invocando
m é -
•
a los
de otros objetos.
Los objetos pueden otros objetos y pueden invocar también los métodos d e otros
o b -
.
crear
• E l código fuente d e una clase determina l a estructura y e l comportamiento (los campos
y
métodos) d e cada uno d e los objetos d e esa clase.
¿
•
C a d a clase tiene un código fuente asociado. → Es el texto que define los
detalles d e una clase.
'Blue]→ Podemos v e r el código fuente d e una clase seleccionando l a función Open Editor
[Abrir Editor) e n e l menú emergente de l a clase o haciendo doble clic sobre
e l icono d e l a clase.

E l código fuente el texto escrito e l lenguaje de programación
Java.
°
es en
•
Compilador → Traduce el código Java a código máquina.
•
Resultado → Los métodos pueden devolver información acerca de u n objeto mediante u n
valor d e retorno.
°
La cabecera de cada método nos d i c e s i e l método devuelve o no u n resultado y cuál e s
el tipo d e e s e resultado.
El tipo de retorno método
de forma parte d e signatura.
•
un n o s u
°
Cuando un método espera un objeto como parámetro, l a signatura d e l método especifica c o m o
tipo d e parámetro e l nombre de l a clase del objeto esperado.
N OTA E D :
↳
signatura: aglutina e l nombre del método,junto con e l número d e parámetros,s u s
[Encabe tipos orden d e los el mismos.
y
zado: l a ampliación del
es concepto de signatura,añadiéndole e l tipo d e
dato que devuelve e s e método los modificadores del método (public,

y
private,...).

TEMA 2: DEFINICIONES DE CLASES
Creación de objetos→ algunos objetos pueden construirse
p r o p oadicional.
rcio -
• no a menos que
información contiene l a cabecera
° E l texto d e una clase s e divide e n dos partes: clase.]
↳
↳
U n envoltorio exterior que sólo d a nombre a la
Una parte interna→ L a q u e hace todo e l

trabajo.]
°
Las palabras c l a v e Java nunca contienen mayúsculas. Contiene campos,
constructores y
^
los campos almacenan datos d e manera persistente dentro d e
métodos.
u n objeto.
°
Los constructores responsables d e garantizar que u n objeto configure
a p r o p i apor d a -
son se
en e l momento d e crearlo primera v e z .

Los métodos implementan e l comportamiento d e objeto → Proporcionan
funcionalidad.
°
un s u
°
Blue]→ campos: fondo blanco.
constructores métodos: fondo amarillo.
y
•
Orden: 1'→ campos.
2 .→ constructores. Almacenan datos d e manera persistente
>
3 :→ métodos. ( dentro de un objeto.
Campos → Almacenan datos q u e objeto tiene

que utilizar.
•
un
↳ s e conocen también como variables d e instancia

l o s comentarios insertan e l código fuente d e clase para proporcionar
e xlos p l i c a -
°
s e e n una
a lectores humanos.
↳
↳ y → comentario d e u n a línea.
entre Ixe y * / → comentarios de varias líneas.
como los campos pueden almacenar valores también

que varíen c o n el tiempo, s e conocen
•
como variables.

! " !
•
Los constructores permiten configurar cada objeto apropiadamente en e l momento d e
crearlo por primera v e z → Inicialización.

↳ Uno de s u s papeles principales es inicializar los campos.
•
E l ámbito d e una variable define l a sección del código fuente desde l a que s e puede
acceder a esa variable.

•
Parámetros - formal→ es e l nombre del parámetro.
↳
\
sólo está disponible para u n objeto dentro del cuerpo d e u n
método
constructor o
que l o declare.
reales →
son los valores del parámetro.
•
El tiempo d e v i d a de u n a variable describe durante cuánto tiempo continúa existiendo
l a variable antes d e ser destruida.

Las instrucciones d e asignación almacenan e l v a l o r representado por
el la
•
de
instrucción en la variable especificada a l a izquierda. expret

s o n elementos q u e calculan
sión
u n valor ←
•
Los métodos están compuestas pordos partes: u n a cabecera u n
y m
E -
e4a É p
contiene
c r e a r espacio adicional de variables temporales.

ara
plaque←
instrucciones: describen las acciones del método.
↳cualquier conjunto de declaraciones e instrucciones situado entre una pareja d e llaves.
•
Instrucción d e retorno(return)→ será siempre l a instrucción final del método.
°
Métodos selectores → devuelven información acerca del estado de u n objeto.→ getters
'Métodos matadores → cambiar el estado de u n objeto. → setters.

-
Operador d e asignación compuesta → + = .
°
E l método System. out-printI n imprime s u parámetro en e l terminal d e texto.
°
Operador d e concatenación → t .

Una instrucción condicional lleva a cabo u n a de dos posibles acciones basándose e n e l
r e s u l -
•
de una prueba a comprobación.
Las expresiones booleanas solo tienen dos posibles valores: verdadero (true) falso(false).
•
y
Se utilizan menudo l a hora d e controlar l a elección entre las dos rutas d e ejecución
e s -
a a
en una instrucción condicional.
" U n ámbito (bloque) e s una unidad de código que normalmente está encerrada entre llaves.
•
BlueJ → l a función "Autolayout", e n e l menú del editor, para corregirsangrado s i está liado.
Una variable local aquella que h a sido declarada u n único método.

y utilizada dentro d e
°
es
S u ámbito su tiempo d e vida están limitados los del propio método.

y a
¿7 Se usan como
E s común inicializarlas
almacenamiento temporal →
en el
para ayudara
s u tarea.
un métodoa completar
>
momento d e declararlas. → Debeninicializarse antes d e poder s e r utilizadas e n u n a
expresión.
Y
Nos e les proporciona un valor predeterminado.
S i e l valor de
campo n o puede modificarse después d e haberlo inicializado inmutable.
.
u n →
-
Un valor d e índice cero representa e l primer carácter d e u n a cadena.
Blue] Cuando e l resultado d e u n a expresión e n e l CodePad objeto, estará marcado

°
→ e s u n
c o n u n pequeño símbolo d e objeto.→ Puede hacerse doble clic sobre é l

rojo para
inspeccionarlo o arrastrarlo a l banco d e objetos para utilizarlo m á s adelante.

TEMA 3: INTERACCIÓN DE OBJETOS
• l a abstracción es l a capacidad d e ignorar los detalles d e las distintas partes, para centrar
l a atención e n un nivel superior d e u n problema.
↳ Dividimos u n problema complejo e n subproblemas sucesivamente hasta que cada
problema individual sea suficientemente pequeño poder resolverlod e manera

para
sencilla.
_ "Divide vencerás!
y
°
La modularización es e l proceso d e dividir todo en partes bien definidas q u e
p uy e -
u n
construirse examinarse por separado y que interaccionen d e formas bien definidas.

Abstracción s e complementan
y modularización entre s í
'
[Modularización divide grandes problemas e n partes m á s pequeñas.

: > abstracción:
p a n o r á -
de
capacidad los detalles centrarse e n l a
ignorar para
general.
•
Las clases definen tipos → Un nombre d e clase puede utilizarse c o m o tipo para u n a
↳las
variable.
variables que tienen u n a clase como tipo pueden almacenar objetos
de dicha clase.
l a declaración de otra variable d e

a u t o tipo
m á t i c aexplícitament
m e n - tipo de clase
°
u n campo a n o crea
u n objeto d e ese → E l campo inicialmente está vacío.

↳ E l objeto asociado debe crearse e?
•
E l diagrama d e clases muestra las clases de una aplicación y las relaciones entre ellas.
↳
|
Proporciona información acerca del código fuente y presenta u n a vista estática
de u n
programa.
> Muestra l a vista estática.
E l diagrama de objetos muestra instante

d e t e r m i -
los objetos relaciones
°
sus en u n
y
durante l a ejecución de una aplicación.

°
E l diagrama d e objetos proporciona información acerca d e los objetos en tiempo de
ejecución y presenta u n a vista dinámica d e u n programa.

°
Cuando una variable almacena u n objeto, e l objeto no se almacena directamente e n
la variable → l o que l a variable contiene es una referencia al objeto.

↳ E l objeto a l
que se hace referencia está almacenada fuera d e l objeto e n el
que aparece la referencia →

objeto e s l o
Esa referencia a que enlaza los
dos objetos entre s í .
"Blue] → sólo proporciona l a vista estática.

°
Referencias a objetos → las variables con u n tipo d e objeto almacenan referencias a objetos.
'tipos primitivos→ Son los tipos

que n o son d e objeto.
↳ Los m á s
↳ comunes s o n :
Están predefinidos en Java.

int, boolean, char, double y long.
"Tipos d e objeto → Están definidos mediante clases.

↳
string.
•
Diferencias → los valores primitivos s e almacenan directamente en una variable.
↳ los objetos n o se almacenan en l a variable (lo que s e almacena e s u n a
referencia a l objeto).
°
OPERADORES LÓGICOS i Actúan sobre valores booleanos y producen u n nuevo valor booleano
como resultado.
↳ 8 8 (and)
£11 (or)
1. (not)
°
Operador módulo (%) → Devuelve el resto de una división.
•
Creación de objetos → Los objetos pueden crear otros objetos utilizando e l operador n e w .
•
E l operador n e w hace dos c o s a s → c r e a u n nuevo objeto de l a clase indicada.
\ Ejecuta el constructor d e dicha clase.

!
°
Sobrecarga→ U n a clase puede tener más d e u n constructor o másd e u n método con el
mismo nombre → siempre que cada uno tenga u n conjunto diferente de tipos
d e parámetro.
°
Llamada a u n método interno→ Los métodos pueden invocar a otros métodos de l a misma
↳
clase como parte d e s u implementación.
N o tiene nombre de variable y punto delante del nombre del método.
no l a necesita→ e l objeto llama a l método d e por s í .
'Llamada a método externo los métodos pueden invocar métodos de otros objetos,
u t i l i punto.]
-
un →
l a notación con
compuesta por u n nombre de objeto, u n punto,e l nombre del método
parámetros d e l a
y los llamada.
°
Diferencia → L a presencia d e u n nombre seguido por u n punto n o s informa d e que e l método
invocado forma parte d e otro objeto.

°
Interfaz → E l conjunto d e métodos que un objeto pone a disposición d e otros objetos.

°
Depurador → Es herramienta d e software ejecuta
u n a
que ayuda a e x a m i n a r cómo s e
µ:::::::.........
>
>
Se puede utilizar
Proporciona funciones
para localizar errores.
u n programa, e n puntos seleccionados d e l

para iniciar y detener
código fuente, a s í c o m o para examinar los valores d e l a s variables.
°
this → S e utiliza cuando hay sobrecarga de nombres→ esto pasa cuando s e utiliza e l m i s m o
}
nombre
para dos entidades diferentes.
Nos permite acceder a un campo cuando existe u n a variable definida m á s próxima c o n e l
mismo nombre.
> Hace referencia a l objeto
actual.

°
Un punto d e interrupción e s u n indicador asociado a u n a línea d e código fuente,que h a r á que
detenga l a ejecución d e método e l momento método.

se un en e n
que s e alcance ese
.
Blue] → para establecer u n punto d e interrupción, abrimos e l editor, seleccionamos l a línea
¿qq
§,,,,,,,,,,,,,,,
apropiada y luego seleccionamos set/Clear B r e a kpoint (configurar/Eliminar punto
de interrupción) e n e l menú Tools (Herramientas) del editor.
.in
s e puede nacer n a a .e u , , , , , µ # a , número d e l a linea ¢ , ¡a.., e n
,,,,,,,,,,,,
cuestión.
> E s necesario compilar primero.
+
step(Paso)→ Ejecuta l a siguiente línea d e código.
StepInto → Entrará dentro del método

que s e está invocando y se detendrá en
l a primera línea d e dicho método.

°
Podemos utilizar e l depurador para observar un objeto mientras s e crea otro.
°
Resumen:
° Podemos tratar d e identificar subcomponentes aquellos objetos
que deseemosmodelar,
e n
así como implementar los subcomponentes mediante clases independientes.
↳ Esto ayuda reducir l a complejidad d e implementación d e l a s

a p l i -
a
d e gran tamaño.
↳ Permite implementar, probar mantener las clases
indivi -
y
por separado.
Este enfoque proporciona estructuras d e objetos
nos
que funcionan
c oparan j u n t a -
-
resolver u n a tarea común.

°
Lo s objetos pueden c r e a r otros objetos e invocar los métodos d e otros objetos.

TEMA 4: AGRUPACIÓN DE OBJETOS
°
l a abstracción n o solo implica ocultar los detalles,s i n o también ser capaz d e detectar los patrones
y l a s características comunes que aparecen u n a

y otra vez e n los programas.
°
Colección → Un objeto colección puede almacenar u n número arbitrario d e otros elementos.
↳ Agrupar cosas para poder referirnos a ellas y manejarlas d e m a n e r a conjunta.
Arrayl i s t → E s l a forma más simple d e agrupar objetos, mediante lista secuencial
d e s o r d e -
°
u n a
de tamaño flexible.
Quienes proporcionan las operaciones específicas d e cada escenario s o n l a s clases
que escribamos para
°
utilizar l a s clases d e l a librería.

°
l a s clases d e librería no aparecen e n e l diagrama d e clases d e Blue].
-
Java denomina a s u s librerías paquetes.
"Instrucción d e importación (import)→ Deben colocarse siempre antes d e las instrucciones de l a s
clases d e u n archivo.
°
Cuando objeto Arrayl i s t tenemos qué tipo d e objetos
a l m a que especificar
-
creamos u n v a a
→ e n e l momento de su creación.
°
Atraylist e s una clase de colección de propósito general → no está restringido e n l o que respecta
los tipos d e objeto

a
que puede almacenar.
↳ Es u n a clase genérica.
>
A utilizar colecciones siempre tenemos que especificar dos tipos:
↳ e l tipo d e l a propia colección
(Ej: Arraylist).
↳ e l tipo d e los elementos que pretendemos almacenar e n esa colección.
•
Notación diamante → Ej: files = new ArrayL i s t estringy1 );
°
Principales métodos de Arrayl i s t → a d d , size, get y remove.
Y
almacena
enl a lista
u n elemento
]
n o s dice cuántos elementos almacena
l a lista actualmente.

°
Características Arrayl i s t :
↳
§
E s capaz d e incrementar s u capacidad interna según s e a necesario.
Mantiene s u propio contador privado, e l número d e elementos q u e almacena.
↳ E l valor del contador l o devuelve e l método s i z e .
> Mantiene e l orden d e los elementos que s e insertan e n l a lista.

↳ E l método a d d almacena cada nuevo elemento a l final d e l a l i s t a .
°
Podemos utilizar Arrayl i s t para escribir cualquier número d e clases distintas que necesiten
almacenar u n número arbitrario d e objetos.
°
l a s clases que requieren un parámetro d e tipo se denominan clases genéricas.
Pueden
definirmuchos tipos a)
•
Los elementos almacenados e n l a s colecciones Arrayl i s t tienen una numeración o posicionamiento
implícito que comienza e n 0.
°
l a posición d e u n objeto dentro d e u n a colección s e conoce como índice.
°
Al primer elemento añadido a u n a colección s e l ed a e l número d e índice 0, a l segundo s e l e d a
e l número d e índice 1 , y así

sucesivamente.
" E l último elemento d e u n a colección tiene como índice s i z e - 1.
•
E l método remove toda c o m o parámetro e l índice del objeto
que hay que eliminar.
↳ Esto puede cambiar los valores de índice e n los que están almacenados otrosobjetos d e
l a colección. → La colección desplazará una posición todos l o s elementos posteriores
para rellenar e l hueco.→ S u s números d e índice disminuirán u n a
unidad.
S e pueden insertar elementos e n Arrayl i s t e n posición distinta del
final d e l a lista.
°
u n u n a
↳ Esto también cambiará l o s índices d e los elementos situados detrás.

•
No suele haber huecos entre los valores d e índice d e los objetos consecutivos d e l a colección.
°
Instrucciones d e bucle = estructuras iterativas d e control.

°
Un bucle s e puede utilizar para ejecutar u n bloque d e instrucciones repetidamente,s i n tener
que escribirl a s múltiples veces.
•
E l bucle for-each tiene d o s partes:
↳
↳
Una cabecera del bucle
Un cuerpo del bucle, situado continuación d e l a cabecera, q u e

c las o n que t i e -
a
instrucciones queremos ejecutar u n a y otra vez.
° Cuando necesitamos más control y hacer más cosas → bucle while.

•
E l bucle for-each → proporciona acceso a c a d a elemento d e una colección, por
|
orden, a través d e l a variable declarada l a cabecera del
[No
e n
bucle.
nos aporta l a posición d e índice d e cada elemento.
tintitaciones
No podemos modificar lo
que e s t á almacenado l a colección
→
en
{S
mientras iteramos a través d e ella.
↳ No podemos n i añadir n i eliminar elementos d e l a
i queremos u n
colección.
valor de índice para los elementos, tendremos

que declarar
nuestra propia variable local.
y mantener
' E l bucle for-each abstrae l a t a re a de procesar u n a colección completa elemento
e l capaz ede manejar -
a
es diferentes tipos de colección.

y
°
No s e recomienda el bucle for-each aquellas tareas las que pueda n o ser
n e c e s a -
e n en
procesar l a colección completa.

-
Iteración definida→ u n a vez
que e l bucle comienza, sabemos con seguridad. cuántas
veces s e v a a ejecutare l cuerpo del bucle → e n e l bucle for-each
ese número será igual a l tamaño d e l a colección.

°
Iteración indefinida → el número de veces que s e ejecutará e l cuerpo del bucle e s
dependerá de l o
que suceda durante
menos preciso → l a itera-

ción → bucle while.
Situaciones e n las que queremos seguir haciendo u n a determinada
cosa hasta que l a repetición deje d e s e r necesaria.

'
E l bucle while → l a condición booleana → l a que controla cuántas v e c e s s
e j e -
e s es e
el código.→ puede ejecutarse c e r o veces.
{ya,,,,
[Un
s i se evalúa como true → se ejecuta el cuerpo del bucle y s e vuelve a
evaluar (cada v e z que ejecute e l cuerpo).

a
,,,, vez
que s e evalúe como false →
puede e va l u a r, c o m o µ,,
se
pa primera v e z
da por terminada l a iteración.
,,,,,,,,,,,,,,,,,,, µ .
ga a ejecutarse nunca.
°
Con e l bucle while, e s posible cometer u n error que haga que tengamos u n bucle infinito.
↳
↳
E l programa parecerá haberse "colgado".
Blue]→ Esto s e detecta porque e l indicador d e "ejecución" a rayas rojas y blancas

p e r m
activado, mientras que e l programa parece n o
a -
hacer n a d a .
-
Ventajas del bucle while:
°
No necesita estar relacionado con u n a colección.
Puede necesitemos procesar todos los elementos, podemos detenernos antes,s i
°
que n o
a s í l o deseamos.
°
Tener una variable d e índice local puede ser
muy importante para realizar búsquedas en u n a
lista → puede proporcionar información sobre dónde estaba ubicado e l elemento.
°
l a s búsquedas son u n a d e l a s formas más importantes d e iteración.
↳
[Tene Un bucle for-each e s inapropiado para búsquedas, porque siempre llevará
su conjunto completo de iteraciones.

a cabo
mos que tener en cuenta que l a búsqueda puede fallar.

-
Posibilidades d e finalización a l escribir u n bucle d e búsqueda:
[la
búsqueda tiene éxito después d e u n número indefinido d e iteraciones.
[Debem
' l a búsqueda
falla después d e agotar todas l a s posibilidades.
os tener e n cuenta las dos posibilidades a l escribir l a condición del bucle.
↳ Ya que l a condición del bucle debe evaluarse como t r u e s i queremos iterar
otra v e z más.
TIPO ITERATOR:
Un iterador objeto
que proporciona funcionalidad para iterar a través d e todos los
e l e m e n -
°
es u n
de una colección.
°
Utiliza u n bucle while para realizar l a iteración y un objeto Iterator e n lugar d e u n a
variable de índice entera para controlar l a posición dentro d e la lista.

°
E l método iterator devuelve u n objeto Iterator.
iterator-mé
Iterator → tipo
°
Iterator está en e l paquete
jarantil.
.
Un Iterator proporciona solo tres métodos:
"hasNext y next s e usan

para iterar a través d e l a colección.
Ej sintaxis: Es a l objeto Iterador a l q u e l e

°
pedimos que devuelva e l siguiente
§
public void listAllTracks(){ elemento no a l objeto colección.
Iterator<Track> it = tracks.iterator(); y
while (it.hasNext){
Track t = it.next();
System.out.println(t.getDetails());
}
}
-
Notenemos que preocuparnos d e l a variable index.
↳ Iterator controla e l punto e n e l que nos encontramos dentro d e l a colección.
Sabe s i quedan más elementos (hasNext) y qué elemento devolver (next)s i es
que todavía quedan.

' l a llamada next hace que e l objeto Iterator devuelva e l siguiente elemento d e l a
c o l e c -
a
y luego avance más allá d e ese elemento.

!
°
Cuando llega a l final d e l a colección, devolverá false a l hacerse una llamada a hasNext.
°
Iterator está disponible para todas l a s colecciones d e l a librería d e clases d e Java.
°
Está prohibido usar e l método remove d e l a colección durante u n a iteración del bucle for-
each.
°
Iterator tiene u n método remove, n o admite ningún parámetro y tiene u n
tipo d e retorno
void. ↳ Hará que s e elimine e l elemento devuelto por l a llamada m á s
reciente a next.
÷
"
" "° "" " " "" " " "" ° " " " " ""
Iterator<Track> it = tracks.iterator();
while (it.hasNext()){
Track t = it.next(); tracks e n e l cuerpo del bucle.
String artist = t.getArtist();
if (artist.equals(artistToRemove)){ te
it.remove();
} Debemos utilizar e l método remove
}
d e Iterator, n o e l d e Arrayl i s t .
•
E l método remove de Iterator flexible→ eliminar elementos
a r b i t r a
n o podemos
-
e s menos
sino sólo e l último elemento extraído por e l método next de Iterator.

→ l a palabra reservada null se utiliza para indicar "ningún objeto"cuando u n a variable
de objeto no está haciendo referencia actualmente a ningún objeto concreto.

•
Todo campo q u e n o haya sido explícitamente inicializado contendrá e l valor n u l l de
manera predeterminada.
°
Si una variable contiene e l valor null, n o s e debe realizar ninguna llamada a método
con ella, → Como los métodos pertenecen a objetos, n o podemos invocar u n método
si l a variable n o hace referencia a un objeto.

↳ Tendremos
que usar u n if para comprobar s i u n a variable contiene n u l l
O no antes de invocar un método sobre dicha variable.

[si hace esta comprobación, s e obtendrá e l tiempo d e
e j e c u -
n o se error e n
NullPointerException.

TEMA 6: COMPORTAMIENTOS MÁS SOFISTICADOS
•
Blue]→ seleccionar Java Class libraries del menú Help.→ Abrirá u n explorador web
m la o s
página principal -
d e l a documentación d e l a API.
°
API =
Application Programming Interface (Interfaz de programación de aplicaciones).
la interfaz d e u n a clase describe l o cómo s e puede utilizar
que u n a clase hace y
°
sin
mostrar s u implementación→ no muestra e l código fuente.
°
E l código fuente que hace que l a clase funcione e s l a implementación.
°
la interfaz d e un método consta d e l a signatura del método y d e u n comentario.
' E l método t r i m d e l a clase string s e usa

para eliminar espacios a l principio y a l final d e l a
cadena de caracteres.
°
U n objeto es inmutable s i s u contenido o estado n o puede cambiarse después d e crearlo.
↳
↳
{lo
l a s cadenas d e caracteres s o n inmutables.
E l método trim n o modifica l a cadena de caracteres y a creada, s i n o

d e
u n a nueva
v
cadena d e caracteres.
u e que
l -
mismo ocurre c o n e l método touppercase
s i queremos modificarnuestra variable de entrada, entonces tenemos

que asignar
otra v e z este nuevo objeto a l a variable (descartando l a original):
input-input.toUppercasel ) ;
input-input.trimf );
E l operador d e igualdad f -
=) comprueba s i cada lado del operador hace referencia a l
°
→
mismo objeto, n o si tienen e l mismo valor.

↳ No u s a r para comparar cadenas → Usar el método
equals.]
Comprueba s i e l contenido d e dos objetos String
equalsIgnoreCase (string anotherstring)← coincide

Clase Random:
aleatorio
•
Paquete Java. Util. Random randomGenerator;
randomGenerator = new Random();
int index = randomGenerator.nextInt();
°
Para crear u n número aleatorio.
-
n ex It n t →
genera un número entero
' n ex tI n t (int n) → genera u n número comprendido entre 0 (inclusive) y n

(exclusive)
.
. clases
parametrizadas o clases genéricas→ al utilizarlas debemos suministrar más
n o m -
uno o
d e tipo entre corchetes angulares

para completar l a definición.
↳ Arrayl i s tr e y o HashMapE K , 1 / 7
°
l a s clasesJava almacenadas e n l a librería no están disponibles automáticamente → debemos
importarlas con l a instrucción import.
"Java utiliza paquetes para clasificar l a s clases d e l a librería

r e l a c i o -
en grupos d e clases
°
Los paquetes están anidados → Pueden contener otros paquetes.
•
E l nombre completo nombre cualificado de clase e l nombre d e s paquete,
s por ey g u i -
o u n a es u
un punto por e l nombre d e l a clase → java.Util.Arraylist.

>
Para importar paquetes completos: import nombre_paquete. * ; → En esta asignatura no lo
haremos a s í .
Clase HashMap:
Es especialización d e Hap (una implementación específica).

"
una
-
Un mapa es u n a colección
que almacena parejas clave)v a l o r como entradas.
°
S e pueden buscar valores proporcionando l a clave.
°
Puede almacenar u n tipo flexible d e entradas.
°
Con Map c a d a entrada n o es u n objeto, sino u n a pareja d e objetos.
↳ un objeto clave y u n objeto valor.
Empleamos e l objeto clave

para buscar e l objeto valor.
°
" l o s mapas son ideales para búsquedas e n u n a sola dirección, donde conocemos l a clave d e

búsqueda y necesitamos saber e l valor asociado c o n e s a clave.
° Los métodos más importantes son: put y get.

°
E l método put inserta u n a entrada e n e l mapa.
•
E l método get extrae el valor correspondiente a u n a clave especificada.
°
Al declarar u n a variable HashMap y a l crear u n objeto HashMap tenemos que indicar qué
tipo d e objetos s e almacenarán e n e l mapa y qué tipo d e objetos s e emplearán como clave.
Cuando objetos de l a s clases genéricas

asigna u n a variable,
°
s e crean s e les es preciso
y
especificar los tipos genéricos (ej: <String, stringy) solo u n a vez e n e l lado izquierdo d e
la asignación, y puede utilizarse e l operador diamante en l a construcción del objeto
d e l a derecha.
Conjuntos:
Un conjunto e s u n a colección
que almacena cada elemento individual
°
como máximo una vez.
°
No mantiene ningún orden específico.
Clase Hashs e t java. u t i .

•
→
•
Introducir u n elemento u n a segunda v e z n o tiene ningún efecto.
Método split →
°
clase string.
↳
{el d e v o l -
puede dividir u n a c a d e n a e n u n a serie d e subc a d e n a s separadas y
en una matriz d e cadenas.
parámetro define c u á l e s e l tipo d e caracteres según l o s cuales 'hay que

d i
l a cadena original → -E j : stringE I wordArray= input-line.split l "
"
);
cortoirárnestracadenarp
cada carácter espaciado

°
Los tipos primitivos n o pueden añadir colección→ necesitan las clases
e (wrappers).
n v o l v e n -
s e a u n a
↳ Cada tipo primitivo tiene una clase envolvente correspondiente que representa e l
mismo tipo, pero es u n tipo d e objeto real.→ L a clase envolvente para i n t

que
es Integer.
°
La técnica de antotoxing s e realiza automáticamente cuando s e utiliza u n valor d e tipo
primitivo en u n contexto que necesita u n a clase envolvente.
↳ Esto significa que los valores d e tipo primitivo pueden añadirse directamente a
÷
una colección. private ArrayList<Integer> markList;
...
public void storeMarkInList(int mark){
markList.add(mark);
}
°
La operación inversa, u nboxing, se realiza también d e forma automática.
°
E l autoboxing s e aplica también siempre que s e transfiera u n valor d e tipo primitivo c o m o
u n parámetro a u n método que espera u n
tipo envolvente, y c u a n d o s e almacena u n
valor d e tipo primitivo en una variable d e tipo envolvente.

°
E l untoxing se aplica cuando se
pasa u n valor de tipo envolvente como parámetro a
método tipo primitivo, y

que espera u n valor d e cuando s e almacena e n
v a -
u n u n a
de tipo primitivo.
°
E l resultado e s casi equivalente a almacenar l o s tipos primitivos e n colecciones.
°
E l tipo d e l a colección debe declararse como u n tipo envolvente
↳ Arraytriste Integery n o Arrayhisteinty.
"
l a documentación d e u n a clase debe ser l o suficientemente detallada como
para q u e otros
programadores pueda utilizar l a clase s i n necesidad d e leer s u implementación.
Javad o c → puede utilizarse para generar l a descripción de l a s interfaces partir del

c ó -
•
a
fuente.

°
Blue]→ Para v e r l a documentación de u n a clase → pulsar e l selector d e l a parte superior
[U
derecha d e la ventana del editor d e Source Code a Documentation.
↳ También seleccionando Toggle Documentation View(cambiar a vista d e
sar d o c u - en e l menú Tools (Herramientas) del editor.
l a función Project Documentation en e l menú Tools d e la ventana principal
documentación d e todas l a s clases d e l proyecto.

para generar l a
°
La documentación d e una clase debe incluir:
El nombre de l a clase
-
-
Descripción del propósito global y características d e l a clase.
-
Número d e versión.
-
Nombre del autor.
Documentación
para c a d a constructor y c a d a método.
-
•
L a documentación d e cada constructor y c a d a método debe incluir:
-
El nombre del método.
-
E l tipo d e retorno.
Nombres los parámetros.
y tipos d e
-
Descripción del propósito

y función del método.
-
-
Descripción d e cada parámetro.
-
Descripción d e l valor devuelto.
°
Cada proyecto completo h a d e tener un comentario global del proyecto e n u n archivo
"ReadMc".
↳
Blue] → Nota d e texto mostrada l a esquina superior izquierda del
d i a -
e n
d e clases.
°
los comentarios e n Javadoc s e escriben entre / ** *
/.
y

Modificadores de acceso:
campo, constructor o método.

°
Definen l a visibilidad d e un
% Los elementos public son accesibles desde dentro d e l a misma clase

y desde otras clases.
° Los elementos private son solo accesibles desde dentro d e l a misma clase.
S e situar a l principio de las declaraciones d e campo

y d e las signaturas d e método.
°
-
L a interfaz d e u n a clase es e l conjunto d e detalles que necesita v e z cualquier otro programador
Proporciona información acerca d e cómo utilizar l a clase.
que la u s e .→
↳
[Es
Incluye las signaturas d e los constructores y los métodos, además d e varios
comentarios.
l a parte pública d e una clase → Define lo que hace l a clase.
' l a implementación define cómo funciona l a clase.
↳
↳ Los cuerpos d e los métodos
y l a mayoría d e los campos.
Es la parte privada de u n a clase → E l usuario d e u n a clase no necesita conocerla.
↳ Principio d e ocultamiento d e información a)

'
public→ declara u n elemento d e una clase como parte de l a interfaz.
°
private→ declara que es parte d e l a implementación.
' E l ocultamiento d e información e s u n principio

que establece que los detalles internos de l a
implementación d e una clase deben estar ocultos a los ojos d e otras clases.
↳ Garantiza una mejor modularización de las aplicaciones.
°
Un programador que haga u s o d e una clase no debería necesitar conocer s u s interioridades.
°
A u n usuario no debería permitírsele conocer e s a s interioridades.
E l primer principio (la necesidad de conocer)tiene que v e r c o n l a abstracción y la

m o d u l a -
-
El segundo principio (que n o s e permita conocer)también tiene que v e r l a modularización.

-
con
↳ Garantiza que ninguna clase dependa d e cómo s e implemente exactamente otra.
↳ Esto e s muy importante

para e l trabajo d e mantenimiento.

°
Cambiar l a implementación de u n a clase n o debería hacer necesario q u e s e modifiquen otras
clases → Acoplamiento.
°
S i los cambios en u n a parte d e u n
programa n o hacen necesario realizar cambios e n otra parte
de u acoplamiento bajo Esto e s positivo
t r a -
n programa
→
o débil → →
Facilita el
de u n programador de mantenimiento.
Las clases deben estar débilmente acopladas → deberían "conocer" (ser
d de)e p e n d i e n -
•
no
los detalles internos d e otra clase.

•
private provoca e l ocultamiento d e l a información a l no permitir que otras clases accedan
esta parte de l a clase garantiza acoplamiento débil y logran
a p l iy fáciles
c a -
a → así s e u n s e
m á s modulares d e mantener.
°
Una tarea de gran envergadura s e descompone e n otras m á s pequeñas para hacerla
m á s manejable → Las subtareas n o están pensadas para ser invocadas desde
fuera de l a clase → s e colocan métodos separados para que l a

i m p l e -
en
de u n a clase sea más fácil d e leer → E s t o s métodos deben ser
privados.
Cuando hace falta t a re a métodos d e clase → E n vez d e
e s c r i -
-
u n a e n varios u n a
el código múltiples veces, se escribe una vez como método privado

y luego
los sitios
se invoca desde e n
que haga falta.
°
los campos también pueden declararse como públicos o privados.
-
Declarar campos como públicos viola e l principio de ocultamiento d e l a información.
↳ Hace clase
que dependa de dicha información
v u fallos
l den e -
una
que sea
a los operación, e n caso de que l a implementación
cambie.
Declarar los campos públicos m a l estilo d e programación.

°
es u n
°
Mantener l o s campos privados otorga a los objetos u n
mayor grado de control sobre
s u propio estado.

°
Blue] → E l mecanismo de finalización de código, con el cursor detrás del punto de
↳ llamada a u n método pulsar CT R L+ espacio.

Puede usarse s i n ningún objeto precedente→ Para invocar métodos locales.
• set → No puede contener elementos duplicados.
\ Métodos heredados de Collection.
•
Hashs e t → Almacena los elementos en u n a tabla hash.
\ E s l a implementación mejor rendimiento d e todas pero n o
g a r a n -
c o n
ningún orden a l a hora d e realizar iteraciones.

°
List → Define una sucesión d e elementos.
\ Admite elementos duplicados.

• Arraylist → Array redimensionable que aumenta tamaño según crece la
c o -
s u
d e elementos.
•
Map→ Asocia claves a valores.
↳ No puede contener claves duplicadas y c a d a clave sólo puede tener u n valor
asociado.
.
HashMap→ Almacena l a s claves e n una tabla h a s h .
↳ Nogarantiza ningún orden a l a hora de realizar iteraciones.
static.
A
°
Las clases pueden tener campos→ variables d e clase o variables estáticas.
D e cada variable d e clase existirá todo momento exactamente

i n d e p e n - que
copia,
-
e n u n a
instanciasdel número d e s e creen de d i c h a clase.

↳ No se almacenan e n el objeto.
•
A l a variable de clase se puede acceder desde cualquiera d e las instancias de la
clase.
°
Todos los objetos d e l a clase comparten esta variable.
-
Estas variables s e emplean cuando tenemos u n v a l o r q u e debe s e r siempre e l mismo

para todas l a s instancias d e l a clase.
°
Métodos d e clase o métodos estáticos → son métodos q u e pertenecen a u n a clase.
°
Constantes:
-
En s u definición s e emplea frecuentemente l a palabra s t a t i c .
-
Similares a las variables, pero n o pueden cambiar d e valor durante l a
e de una
j e
aplicación. c u -
¡Garantizaq después
ue puedas e r n o
-
S e definen mediante l a palabra clave final. modificadode manera
accidental.
-
Diferencias c o n l a declaración d e u n
campo:
°
Incluyen l a palabra final antes del nombre del tipo.
° Han d e inicializarse con u n valor en e l momento d e l a declaración.
-
s e suelen escribir e n mayúsculas.
E s frecuente apliquen todas l a s instancias d e clase
c o n s -final y static.
-
s e u n a →
que a
d e clase → se declaran c o n
L a declaración constantes públicas

py r o b l e -
-
de como n o suele generar ningún
a veces resulta útil.
muy
•
Métodos d e c l a s e :
-
Pueden invocarse sin ninguna instancia - basta con tener l a clase.
-
Pertenecen a l a clase n o a u n a instancia.
y
-
Pa r a declararlo se añade s t a t i c delante del nombre de tipo e n la
c a
d e l método. -
-
s e i n v o c a especificando e l nombre de l a clase e n l a que se ha definido,
delante del punto e n l a notación habitual.
- Presentan limitaciones importantes:
Tienen restricciones l a s variables d e clase desde s

para acceder a
°
u
clase ya que los campos d e instancia objetos
i n -
→ s e asocian c o n

°
U n método d e clase n o puede invocar a u n método d e instancia desde
l a clase → sólo puede llamar a los métodos d e clase definidos e n s u
clase.
•
E l método principal: → M i r a re n Apéndice E .
-
Pa r a i n i c i a r una aplicación Java sin Blue].
- Inicialmente no existen objetos, sólo clases → El primer método que tenemos
método d e clase.
que i n v o c a r
es u n
E l u s u a r i o especifica l a clase q u e debe iniciarse e l sistema
i n v o c a -
Java
-
→
e l método m a i n e n esta clase.

-
Si en esta clase no existiera t a l método s e comunicaría u n error.

TEMA 7: COLECCIONES DE TAMAÑO FIJO: MATRICES
°
Cuando creamos e l objeto de colección, tenemos que especificar e l número máximo d e
que puede almacenar este número suele

elementos →
que n o podrá modificarse →
mantenerse
fijo e n todo el tiempo de vida de l a colección.
MATRICES:
Una matriz tipo especial de colección que puede almacenar número
fijo
°
es u n u n
de elementos.
Una colección de tamaño llama matriz.
fijo
•
se
• Ventajas→ El acceso a los elementos almacenados e n una matriz suele ser más
{lasflexible
eficiente que el acceso a los elementos d e una colección d e tamaño
comparable.
matrices pueden almacenar tanto objetos c o m o valores d e tipo

p r Las i m
colecciones d e tamaño i -
flexible sólo pueden almacenar
o b j e -
→
°
Tiene u n soporte sintáctico especial→ se puede acceder a ellas c o n ayuda d e u n a
sintaxis personalizada que difiere de las llamadas tradicionales a métodos.]

°
Son l a estructura de colección m á s antigua utilizada en los lenguajes de programación.
°
La característica distintiva d e l a declaración d e u n a variable d e tipo matriz e s u n a pareja
de corchetes que forman parte del nombre del tipo- i n t[7-→ matriz d e enteros.
int e s el tipo base de estaa )

E s t a matriz almacenará
Matriz concreta - valores d e tipo i n t
°
L a declaración de u n a variable de matriz n o crea pors í mismo e l objeto matriz → esto s e
hace utilizando e l operador
f -
n e w. declaración
private int[] hourCounts;
hourCounts = new int[24];→
24 n o e s u n parámetro,e s e l tamaño creación objeto matriz
d e l a matriz. parámetrosconstruct T
°
No hay paréntesis para los orto matriz n o tiene constructor.

!
°
Cuando s e asigna u n objeto motriz a u n a variable motriz, e l tipo d e l objeto matriz debe
c o con -tipo
el declarado para l a variable.
°
Inmediatamente después d e s u creación, u n objeto motriz está vacío.
↳
↳
s i es u n a matriz para objetos→ contendrá valores null.
si es una matriz int→ todos s u s elementos se inicializarán con e l valor cero.
°
A los elementos individuales de una matriz s e accede indexando l a m a t r i z → u n índice
e s u n a expresión entera escrita entre corchetes y que s e coloca después d e l nombre d e
y
una variable de matriz - labels[6]
machines[0]
°
los índices d e u n a matriz siempre comienzan e n cero y van hasta u n a unidad menos que l a
longitud de l a matriz.
↳ Utilizar e l valor de l a longitud d e l a matriz como índice producirá u n error
e n tiempo de ejecución: ArrayIndex OutOfBoundsException.
Las expresiones
que seleccionan u elemento d e matriz pueden utilizarse
°
n u n a en cualquier
lugar donde se pueda emplear u n a variable del tipo base de l a matriz.
•
La utilización d e un índice d e matriz en e l lado izquierdo d e instrucción d e
a s i g n a (set) -
una
e s e l equivalente a un método matador →

modificará e l contenido d e l a
matriz.
° L a utilización d e un índice d e matriz e n cualquier otro lugar es e l equivalente a u n
método selector (get). t o que s e incrementa e s el
#hourCounts[hour]++; valor almacenado e n e l elemento

d e l a matriz y no l a variable
hour.
# hourCounts[hour] += 1; equivalent
hourCounts[hour] = hourCounts[hour] + 1;
e
a esto
°
Todaslas matrices tienen u n campo length que contiene e l valor d e s u tamaño fijo.
↳ s u valor s e corresponde con e l d e l a expresión entera utilizada para c r e a r e l objetomotriz.

E L B U C L E FOR:
•
Hay 2 variantes → bucle for-each→ conveniente
para iterar a través d e u n a colección
↳
de tamaño flexible.
bucle for → apropiada cuando:

°
queremos ejecutar u n cierto conjunto d e instrucciones u n
número fijo de veces.
° necesitamos una variable dentrodel bucle cuyo v a l o r

c en una
acantidadmfija, -
incrementándose normalmente
en 1, en cada iteración.
.
E s t á bien adaptado a aquellas situaciones e n las que s e necesita u n a iteración definida.
•
Forma general: losparéntesis contienen
instruccionesqueha
for (inicialización; condición; acción post-cuerpo)
{ tressecciones indepen-
dientes, separadas por
yquerep
punto y coma.
}
°
S i queremos eliminar elementos d e u n a colección mientras iteramos a través de ella con u n bucle.
fori
-inguna
for(Iterator<Track> it = tracks.iterator(); it.hasNext();){
Track t = it.next();
if(track.getArtist().equals(artist)){ post-
acción
}
it.remove();
del bucle
cuerpot
}
teniendo#n
pero seguimos e incluir el
puntoy coma después d e l a condición
del bucle.

•
Autómatas celulares → Estructuras computacionales relativamente sencillas
que
m pautas ud e "conducta".
e s -
E l operador condicional → A menudo solo para simplificar l a expresión d e las
i n if-else.
s t r u c -
•
s e usa
[Se↳Consiste
en los dos caracteres?y : .
llama operador ternario → toma t r e s operandos.
↳ S e utiliza para seleccionar d e los dos valores alternativos,
b a s á n -
u n o
e n l a evaluación d e u n a expresión booleana.
- l a condición e s true, e l valor d e l a expresión completa

Si
condición ? valor1 : valor2
será valor1 , e n e l c a s o contrario,s erá valor2 .
La clase HashMap permite

par (clave, valor).
entre objetos
°
crear asociaciones e n l a forma d e u n
°
U n mapa e s u n a forma general de tabla de búsqueda → l a clave s e utiliza para buscar u n
valor asociado en e l mapa.
Las matrices ofrecen u n a cómoda implementar tallas d e búsqueda

y eficaz de
^
manera
e s - aplicaciones
que l a clave valor tomado d e intervalo
n ú m e -
e n e n e s u n u n de
enteros, y no u n objeto.
↳ Para ajustarse la forma d e indexar las colecciones, e l intervalo debe tener e l
[g,
a
0 como s u valor mínimo.
'empre que s e conozca e l tamaño del intervalo posible matriz

d fija i m e n -
e s crear u n a de
e n l a que se guarden los valores del par(clave,valor), donde l a clave e s u n
índice entero basado en 0.
°
Códigos d e Wolfram → Estudio con los 2 5 6 autómatas celulares elementales posibles.
Propuso u n sistema numérico p a r a definir l a conducta d e cada tipo d e autómata,y e l
código asignado a cada uno recibe e l nombre d e código d e Wolfram.

!!
TEMA 8: DISEÑO DE CLASES
°
E l diseño d e clases debe estar dirigido por e l concepto d e responsabilidad.
•
Las clases deben encapsular los datos correspondientes.
Muchos d e los efectos de mal diseño d e clases hacen especialmente obvios a l tratar d e
°
u n s e
adaptar o ampliar u n a aplicación.

°
Hay dos términos que s o n fundamentales e n l a calidad d e u n diseño d e clase: e l acoplamiento
y l a cohesión.
°
Acoplamiento→ describe l a interconexión entre l a s clases.
↳ Lo q u e buscamos e n u n sistema e s u n acoplamiento débil → u n sistema e n elque cada
clase s e a fundamentalmente independiente

t r a -
se comunique con l a s otras clases
y a
de u n a interfaz compacta y bien definida.

°
E l grado d e acoplamiento indica l o estrechamente conectadas que están l a s clases.
Determi na
l o difícil
que e s realizar cambios e n u n a aplicación.
°
En estructura d e clases estrechamente acoplada, u cambio clase puede hacer
n e -
u n a n e n u n a
introducir cambios también e n otras clases → Esto es lo

que tratamos d e evitar.
↳ localizar todos los lugares los necesario hacer cambios y llevar a l a
p r á cdifícil
que e s
-
e n
esos cambios puede resultar y requerir mucho tiempo.

°
En u n sistema débilmente acoplado, podemos cambiar una clase sin efectuar ningún cambio
en las clases restantes, y
l a aplicación seguirá funcionando correctamente.
°
Cohesión→ Describe l o bien unidad d e código s e corresponde c o n u n a tarea lógica
que u n a
¢
o con u n a entidad.
En sistema
un
muy cohesionado, c a d a unidad d e código (método,clase
o
responsable d e tarea entidad bien definidas.
es
u n a o
paquete
> Un buen diseño d e clases exile u n alto grado de cohesión.
•
Cada unidad d e código debe ser responsable d e u n a tarea coherente → una tarea que
pueda s e r visto como u n a unidad lógica.

°
C a d a método debería implementar u n a operación lógica y cada clase debería representar u n
tipo d e entidad.
Principal razón del principio d e cohesión: l a reutilización → Si método o clase
r e s p o n -
°
u n es
de una única cosa bien definida, e s mucho m á s probable que pueda utilizarse d e nuevo
e n u n contexto distinto.
Otra ventaja → cuando haga falta realizar modificaciones algún aspecto de l a
a p l i -
>
e n
e s probable
que
encontremos todas las piezas relevantes dentro de u n a misma unidad.
La duplicación d e código (tener e l mismo segmento d e código

°
en u n a aplicación m á s d e
u n a vez) e s un signo d e mal diseño → se debe intentar evitar.
↳ incrementa l a cantidad de trabajo → cualquier modificación e n u n a versión debe
ser realizado también e n l a o t r a → introduce el peligro d e que aparezcan errores.

•
l a duplicación de código e s u n síntoma de mala cohesión.
°
Cuando solo cambia l a implementación d e u n a clase, otras clases n o deberían verse afectadas.
↳ Tendremos u n acoplamiento débil.
.
Una adecuada encapsulación d e l a s clases reduce e l acoplamiento conduce, por tanto, a
y u n
↳
→ Es d e los principios fundamentales d e u
" " "°" buen diseño d e clases.
"él" u n o n
Ocultar la información d e l a implementación a ojos d e otras clases.

°
ta encapsulación
sugiere que solo debe hacerse visible para e l exterior l a información acerca
de l o que hace u n a clase, n o l a información a c e r c a de cómo l o hace.

- Ventaja→ S i ninguna otra clase sabe cómo está almacenada nuestra información, entonces
podemos cambiar fácilmente e l modo e n

que está almacenada s i n por ello hacer que otras
clases dejen de funcionar_

↳ Definiendo los
campos c o m o privados y utilizando
m é -
u n
selectorpara acceder a ellos.

En lugar de acceder a u n campo público, y
usamos u n a llamada a método.

Nunca podemos desacoplar completamente entre s í l a s clases d e u aplicación →
h i c i é -
•
n a s i lo
los elementos d e las distintas clases n o serían capaces d e interaccionar entre s í .
↳ Lo q u e intentamos es mantener e l grado d e acoplamiento l o m á s bajo posible.
Diseño dirigido por responsabilidad:
°
Hacer u s o d e u n a encapsulación adecuada reduce e l acoplamiento
y puede d i s m i n u i r
signi - l a cantidad de trabajo necesario para llevar cabo cambios e n
a p l i c a -
a u n a
°
l a encapsulación n o es el único factor que influye e n e l grado d e acoplamiento.
' E l diseño dirigido por responsabilidad e s e l proceso d e diseñar clases asignando unas
responsabilidades bien definidas a cada clase e l acoplamiento.

→
Influyee n
↳ Puede emplearse
qué clase debería implementar cada
{
para determinar
parte d e u n a función de l a aplicación.
> Expresa l a idea de que cada clase debe s e r responsable d e gestionar s u s propios
datos.
Preguntarnos: ¿Qué clase debería s e r responsable de l a
tarea?]
^
L a c l a s e responsable de almacenar determinados datos debería s e r también
r e s p o n -
°
unos
de manipularlos.
°
Uno d e los principales objetivos d e u n buen diseño d e clases e s e l d e conseguir l a localidad d e
los cambios → hacer cambios e n u n a clase debería tener u n efecto mínimo e n las clases
↳
" " " "si
podemos
conseguiresto siguiendo unas buenas reglas d e diseño
↳ Emplear u n diseño dirigido por responsabilidad, tratar d e conseguir

u n acoplamiento débil una a l t a cohesión.
y
'
Deberíamos tener en mente las futuras modificaciones y ampliaciones e n e l momento d e crear
nuestras aplicaciones.

°
El uso d e campos públicos tiende a crear fuerte acoplamiento entre clases.
°
E l acoplamiento implícito e s u n a situación e n l a que u n a clase depende d e l a información
interna d e otra, pero dicha dependencia no es inmediatamente obvia.
↳ La omisión d e u n cambio necesario puede n o ser detectada.

°
L a s flechas e l diagrama d e clases buena indicación aproximada d e l a
e s t r e c h a m e n -
e n s o n u n a
acoplada que está u n programa → cuantas m á s flechas, mayor acoplamiento.

°
Una buena práctica de diseño consiste e n tratar d e encapsular toda l a información acerca de l a
interfaz d e usuario en una única clase, o en u n conjunto d e clases claramente definido.

•
Patrón modelo-vista-controlador (model-view- controller)
↳ 6 0" "
¡pon.trepeat.MN
oqomoygqganiz
eqqogramm.mg
structured Programming.
•
"Cohesión d e métodos→ c a d a método debe s e r responsable d e u n a , y solo una, tarea bien
↳ E s mucho m á s
definida.
fácil entender l o que hace u n segmento de código y es también
más fácil realizar modificaciones en e l mismo, s i s e utilizan métodos cortos y
fáciles d e entender, y s u s nombres indican s u propósito de forma bastante

clara.
• Cohesión de clases→ Cada clase debería representar única entidad bien
una definida
dentro del dominio del problema.
Maneras que u n a alta cohesión beneficia a diseño → legibilidad reutilización.

•
en u n
y
Incrementar l a cohesión hace que u n a clasela
t
más las tareas separadas
legibly
re u t i l i -
sea pueden
Más fácil de entender y mantener < m á s fácilmente.

>
L a refactorización e s l a actividad consistente en reestructurar u n diseño existente para
m u n
a n
buen diseño d e clases cuando s e modifica - o amplía l a aplicación.
↳ Consiste
↳ repensar y rediseñar l a s estructuras d e clases y métodos.

e n
E l efecto más común es

que las clases s e dividan e n dos o
que los métodos s e dividan
en dos o m á s métodos.
Antes d e refactorizar debemos asegurarnos de
que exista conjunto d e pruebas para l a versión
°
u n
actual del programa.

°
La refactorización debe hacerse e n dos etapas:
11) Refactorizar para mejorar l a estructura interna del código, pero s i n realizar
ningún cambio e n l a funcionalidad d e l a aplicación.

↳ E l programa debería comportarse de l a misma forma exacta que
Habrá
antes. que repetir las pruebas para verificar que n o
→
h e
introducido errores inadvertidamente.
-
E ) Una v e z que hayamos restablecido l a funcionalidad
r e f a c t o r i z a -
base e n l a versión
→
mejorar e l programa → realizar pruebas c o n l a n u e v a versión.
Hacer varios cambios a l mismo tiempo frefactorizar características) hace

y añadir
°
nuevas
que
sea más difícil localizar las fuentes de error e n c a s o de que s e introduzcan errores.
°
E n l a refactorización reestructuramos l a forma representamos nuestros datos para
e n
que
conseguir un mejor diseño c o n unos requisitos modificados.
↳ Cuanto antes limpiemos nuestro diseño, más trabajo n o s ahorraremos.

°
Una d e las cosas
que h a r á que l a refactorización nos complique l a vida a largo plazo
es
que n o
probemos adecuadamente la versión refactorizada comparándola c o n l a original.
↳ Resulta esencial garantizar ques e prueben las cosas adecuadamente, antes
y
después del cambio.

! "
Tipos enumerados:(pág. 314-319)
°
Una definición de tipo enumerado consta d e u n envoltorio exterior que u t i l i z a l a palabra
lugar de class y de cuerpo que e s simplemente lista d e nombres

v a -
enum en u n u n a
que i n d i c a e l conjunto d e valores pertenecientes a este tipo.

•
Porconvenio, estos nombres variables s e escriben siempre e n mayúsculas.
•
Nunca crearemos objetos de tipo enumerado → c a d a nombre contenido e n l a definición
del tipo representa una instancia diferente d e ese tipo que y a ha sido creada para que
l a podamos emplear.
°
La sintaxis para utilizarlas es similar a las constantes d e clase.
•
l o s valores d e tipo enumerado son realmente objetos, no equivalen a números enteros.
y
Í
e n e l lugarde public enum CommandWord{
// Un valor para cada palabra de comando, más otro
// para los comandos no reconocidos.
se invocan COMO GO, QUIT, HELP, UNKNOWN;
}
lasconstantes de
clase:
Command.Word-GO, porconvenio,siempree n mayúsculas
CommandWord.QUIT...
°
Una instrucción switch selecciona u n a secuencia d e instrucciones para s u ejecución a partir
de u n a serie de múltiples opciones diferentes. → Apéndice D (pág.610).
°
Los constructores d e los tipos enumerados n u n c a son públicos→ No s o m o s nosotrosquienes
creamos las instancias.

°
Restricciones e nu n → Una enumeración no puede heredar d e otra clase.
→ Una enumeración no puede s e r u n a superclase.
Cada d e las constantes d e enumeración objeto de l a clase e n l a

que está
d e -
°
una es u n
°
Enum puede implementar muchas interfaces.
•
Todo tipoenumerado define u n método values que devuelve u n a matriz llena con los objetos

correspondientes a
los valores del tipo.
° Directrices de diseño:
-
Un método es demasiado largo s i lleva a cabo más d e una tarea lógico.
-
Una clase es demasiado compleja s i representa más d e una entidad lógica.
°
Resumen:
-
U n buen diseño de clases puede implicar u n a enorme diferencia a l a h o r a d e
c o
modificar o -
ampliar u n a aplicación.
-
Hay dos conceptos clave que permiten evaluar e l diseño d e las clases:
• E l acoplamiento hace referencia a l a interconexión entre l a s clases.
°
La cohesión s e refiere a l a modularización en unidades apropiadas.
-
Un buen diseño tiene un acoplamiento débil y una a l t a cohesión.
Una forma d e buena estructura de diseño

d i r i -
-
conseguir una es seguir u n proceso
responsabilidad.
por
↳ Cada v e z que añadamos
i n t equé n t a r e -
una funcionalidad a l a aplicación,
identificar clase debe s e r responsable de cada parte d e l a
tarea.
-
A l ampliar un programa → usamos periódicamente la refactorización para
Íadaptareciénascambisequi
sitosgarantizar que las clases y los continúen estando métodos
c o yh e -
>
sigan estando débilmente acoplados.

TEMA 9: OBJETOS CON UN BUEN COMPORTAMIENTO
°
Errores sintácticos → s o n errores e n l a estructura del propio código fuente.
↳ Fáciles de localizar → E l compilador los resaltará
y mostrará algún
tipo d e mensaje de e r r o r ,
°
Errores lógicos → Es u n problema e n e l q u e e l programa s e compila se ejecuta s i n que s e
y
↳ produzca ningún e r r o r obvio, pero n o s proporciona e l resultado incorrecto.

Mucho m á s difíciles d e localizar.
°
Actividades relacionadas con la tarea d e mejora d e l a corrección d e u n
programa:
-
Pruebas.
-
Depuración.
-
Escritura de programas c o n vistas a s u mantenibilidad.
• Pruebas → son l a actividad consistente en averiguar s i u n fragmento d e código

(un método, u n a clase o u n programa) presenta e l comportamiento deseado.
°
Depuración → Es e l intento de localizar y corregir e l origen d e u n e r r o r.
↳ Viene detrás d e
las pruebas.
•
Escritura de programas para s u mantenibilidad → E l tema más fundamental.
↳ Es intentar escribir código d e t a l m a n e r a ques e eviten
{
en primer lugar l o s
errores y que s i producen, puedan s e r encontrados l o más fácilmente

se
po.
sine.
> E l estilo d e codificación y los comentarios son parte de esta tarea.
↳ E l código debería s e r
fácil de entender.
•
l a s pruebas y l a depuración son habilidades cruciales e n e l desarrollo de software.
°
Cuando e l programa es d e otra persona, l a tarea d e depuración estáestrechamente relacionada
con e l proceso d e comprender e l código escrito por algún otro programador.

Prueba de unidad dentro de BlueJ:
•
l a prueba de unidad s e refiere a las pruebas d e las partes individuales d e u n a aplicación,como
los métodos
y las clases.
°
Pruebas d e l a aplicación → consisten e n probar l a aplicación completa.
°
Las unidades sometidas a prueba puedens e r de diversos tamaños→ u n
grupo d e clases,
una única clase 0 u n único método.
°
Puede hacerse mucho antes d e completar u n a aplicación.
•
Cualquier método puede (y debe) s e r probada después d e haber sido escrito y compilado.
° Ventajas d e las pruebas experimentación tempranas:
y
↳
[Pod
Puede permitir detectar los problemas lo suficientemente pronto c o m o
para poder
resolverlos.
emos empezar a construir u n a serie de c a s o s y resultados d e prueba que s e
pueden utilizar que e l sistema crece.
y otra
una vez a medida
↳ Cada v e z que hagamos u n cambio en el sistema, estos c a s o s d e

prueba n o s permitirán comprobar que n o hemos introducido
inad - errores e n el resto del sistema.
•
La naturaleza interactiva de Blue] permite simplificar partes de l a s pruebas, realizando
m o d i - controladas en las clases que estamos probando.

•
Algo esencial a l a hora d e probar clases que utilicen estructuras de datos e s comprobar que s e
comportan apropiadamente tanto cuando l a s estructuras d e datos están vacías c o m o cuando
están llenas las llenas sólo s e pueden hacer las que tienen u n límite
→ con
fijo, c o m o
las matrices.
°
Hacer pruebas con u n a lista v a c í a es importante → es u n caso especial.
'
Una característica clave de unas buenas pruebas consiste e n asegurarse d e que comprueben
los límites → suelen s e r los puntos donde l a s cosas dejan d e funcionar.

•
Prueba positiva→ E s l a prueba d e u n caso
que s e espera que funcione correctamente.
↳ Buscamos convencernos d e que el código h a funcionado c o m o s e esperaba.
Prueba negativa → E s l a prueba de u n

que s e espera que falle.
°
caso
↳ Esperamos que el programa maneje e s e error d e forma especifi-
[¿{a
una
Y controlada.
| 'ates para u n buen procedimiento d e pruebas.
° Automatización d e pruebas → simplifica e l proceso d e pruebas d e regresión.
E s deseable ejecutar pruebas d e regresión c a d a

que s e realiza u n cambio e n e lsotware.
°
vez
te
Implica volver a ejecutar pruebas que y a s e pasaron anteriormente con éxito,
para garantizar que l a n u e v a versión sigue superándolas.
•
Una de l a s formas m á s sencillas de automatizar las pruebas de regresión consiste e n
de pruebas.
escribir u n programa que actúe c o m o marco
Blue] incluye u n soporte

para las pruebas d e regresión utilizando e l sistema J U
nit.]
•
{ E s u n entornod e pruebas
que soporta l a
Paraactivar l a s herramientas d e prueba, prueba estructurada d e unidades y l a s
pruebas d e regresión e n Java.
accedera l a pestaña Interface del
c d eudiálogoaPreferencias
-y esté seleccionada l a opción Mostrar
h e para la realización
-
asegurarse d e que
de pruebas de unidades.
°
Utilizando clases de prueba podemos automatizar l a s pruebas d e regresión.
°
l a clase d e prueba contiene e l código para llevara cabo una serie d e pruebas preparadas
y comprobar sus resultados → a s í repetir l a s mismas pruebas e s mucho m á s sencillo.

•
C a d a clase de prueba está asociada con u n a clase normal del proyecto.
E l código fuente d e las clases d e prueba e s generado automáticamente

por Bluey.
°
°
C a d a clase prueba suele contener pruebas p a r a verificar la funcionalidad de
s u clase de referencia → se crea utilizando e l botón derecho del ratón sobre

una clase de referencia potencial y seleccionando crear clase d e prueba.
•
l a clase d e prueba contiene tanto código fuente
para ejecutar pruebas sobre
una clase d e referencia, como para comprobar s i las pruebas h a n tenido éxito
O N O.
°
Grabación de u n a prueba:
-
l a s pruebas se graban indicándole a
Blue] que comience a
grabar,
realizando l a prueba manualmente y luego indicando que l a prueba
h a finalizado.
-
Primer paso → a través del menú asociado a u n a clase d e prueba.
(Esto le dice a Blue] e n qué clase queremos almacenar l a prueba).

-
Seleccionamos c r e a r método de prueba → Especificamos u n nombre
para el método d e prueba → Por convención, los nombres d e l a s

pruebas comienzan por test → @Test.
Una iniciada l a grabación, llevamos a cabo las acciones que
e j e c u t a r í a -
-
vez
con u n a prueba m a n u a l normal.

• Aserción → Es una expresión establece condición que esperamos s e a cierta.
que una
✓ ↳ s i l a condición e s falsa, decimos

que l a aserción h a fallado → Esto
pág.336-337 indica que hay algún e r r o r en nuestro programa.
°
Banco d e pruebas → Es u n conjunto d e objetos en u n estado definido que s i r v e n c o m o
[s
base
para realizar pruebas de unidades.
-
E n e l menú
hay dos opciones D e l banco de objetos a l banco d e pruebas y
Del banco de pruebas a l banco d e objetos.
e
an.am a , m # a . * µ →
que, ¡ n o , automáticamente µ , antes
de invocar cada método de prueba → @Before.
>
los métodos de prueba individuales necesitan crear s u s propias versiones d e
ya n o
los objetos contenidos e n e l banco de pruebas.

• Recorrido manual → Es una actividad consistente en analizar u n segmento de
{¡µ, [Es código línea a línea mientras

que s e observan los cambios
d e estado otros comportamientos d e l a aplicación.
y
una simulación hecha con
lápiz y papel de lo que sucede dentro
d e l a computadora cuando s e ejecuta u n programa.
µ,,,,,,,,,,,,,,,,,,,,,,,,,,,
°
U n a parte importante d e l a realización del recorrido manual consiste e n asegurarse d e
que siempre dispongamos d e u n a representación precisa d.e l estado del objeto.

↳ Dibujar tabla los campos del objeto y valores
c o r r e s p o n para
dien -
u n a con sus
→ Así e s sencillo volver atrás comprobar cualquier detalle
y también e s
posible comparar los estadios después d e dos llamadas al
mismo método.
• Recorridos verbales→ Tratar de explicar a otra persona l o que hace u n a clase o
método.
Instrucciones de impresión → L a técnica m á s común utilizada para comprender
d e -
•
y
"
↳
{proporc
programas.
{µ,,,,,,,,,,,,,,,,,
Consiste e n anotar temporalmente los métodos mediante
ionarán u n a serie d e instrucciones d e impresión.
información a c e r c a d e :
-
los métodos que s e h a n invocado.
l o s valores d e los parámetros.
,,,,,,,,,
-
E l orden e h a n invocado los métodos.

n
que s e
-
-
Los valores de las variables locales y los campos e n ciertos
puntos estratégicos.
tizar errores.

• Desventajas d e las pruebas d e impresión:
-
No suele s e r práctico a ñ a d i r instrucciones d e impresión a todos los métodos
de una clase → sólo s o n efectivas s is e introducen e n los métodos correctos.

-
Añadir demasiadas puede conducir a u n a sobrecarga d e información.
-
Puede resultar tedioso eliminarlas después.
Puede
que hagan falta
-
después de haberlas eliminado.
°
Las instrucciones d e impresión s e añaden a menudo a u n s o l o método c a d a v e z 0 a
unos pocos métodos, cuando tenemos u n a idea aproximada d e en qué á r e a d e nuestro
programa s e oculta el error que estamos buscando.

•
Depurador → podemos utilizarlo para localizar er rores.
¢
Es herramienta software que proporciona soporte realizar
r e c o -
una para u n
de u n segmento d e código.
ventaja → se encarga automáticamente de anotar e l estado * c a d a objeto

↳ es más rápido y menos susceptible a errores.
• Desventaja, → suelen mantener

e s t a -
n o u n registro permanente d e los cambios d e
→ es más difícil i r hacia atrás y comprobar c u á l e r a e l
estado hace unas cuantas instrucciones.

•
Los depuradores también proporcionan información acerca de l a secuencia de llamadas
( o pila de llamadas) e n c a d a momento. £

Contiene u n registro d e todos l o s métodos
finalizado,
↳
n o
que están actualmente activos.

Bluejosestá e n l a parte izquierda de l a ventana del depurador.
↳ podemos seleccionar cualquiera d e los nombres d e métodos
s e c u e n las -
e n esa
para inspeccionar los valores actuales de variables locales d e dicho
método.

TEMA 10: MEJORA DE LA ESTRUCTURA MEDIANTE LA HERENCIA
Al iniciar proyecto Primero tenemos

que decidir qué clases utilizaremos.
°
un →
Los objetos d e estas clases deben encapsular todos los datos

que deseemos almacenar
•
acerca
de esos objetos.
Algunos de elementos deberán tener métodos selectores

y matadores.
•
esos
•
No e s importante en este momento decidir los detalles exactos d e todos los métodos
-
sólo queremos tener una primera impresión del diseño de esta aplicación.
•
E l estilo de notación para los diagramas de clases utilizados en el libro y e n Blue] e s u n
subconjunto de l a notación 4Mt.
✓ \ " " " " "define cómos e muestran los campos,

L a clases e divide e n dos partes
que losmétodos e n
← un diagrama d e clases.
indican e l nombre de la clase, los
campos y los métodos,
•
Blue] → s e centra en las clases definidas por e l usuario
↳ n o muestra los nombres d e los campos n i de los métodos e n e l diagrama.
• L a herencia nos permite definir u n a clase como ampliación d e otra.
↳ Ventaja → Hace describir las características
que solo s e a necesario comunes
u n a vez →
evitando l a duplicación d e código.
•
Java utiliza l a palabra clave extends para definir l a relación d e herencia.
•
Las flechas ( I ) e n el diagrama d e clases, representan l a relación d e herencia.
↳ son flechas con cabeza hueca.
•
Superclase Toda clase ampliada por otra clase.
→
que es
•
Subclase → Una clase que amplía (hereda de) otra clase.
µ > Es
Hereda todos los
u n a
campos y
especialización de u n a superclase.
métodos d e s u superclase.
°
L a herencia se denomina e n ocasiones relación e s - u n .
•
Las instancias d e las s u bclases disponend e todos los métodos definidos tanto en la
superclase como e n la subclase.

•
Las clases que están vinculadas por relaciones d e herencia forman u n a
jerarquía d e
herencia.
l a herencia técnica de abstracción que n o s permite categorizar las clases d e
o b -
•
es u n a
mediante ciertos criterios y nos ayuda a especificar las características d e
esas clases.
•
Hna subclase no puede acceder a los miembros privados d e s u superclase
accederatae
Estos s e modificarán o
campos s e
mediante los métodos públicos apropiados l a superclase.

que proporcione
•
Una subclase puede accedera los elementos n o privados d e su superclase sin necesidad
de utilizar ninguna sintaxis especial.

°
Constructor de l a superclase → E l constructor d e u n a subclase debe siempre invocar
a l constructor de s u superclase como primera instrucción.

↳ s i e l código fuente no incluye e s a llamada,Java intentará insertar u n a llamada
automáticamente → estosólo funciona s i l a superclase tiene u n constructor
s i n parámetros → s i no producirá u n error.
•
La palabra super hace l a llamada desde e l constructor d e l a subclase a l d e l a superclase.
•
siempre conviene incluir llamadas explícitas a l a superclase e n los constructores
↳
↳ es u n buen estilo d e programación.
evita l a posibilidad de interpretaciones erróneas y confusión.

°
La herencia nos permite reutilizar l a s clases previamente escritas dentro d e u n nuevo contexto.
↳ hace falta m u c h o menos código n u e v o .
°
Cuando l a jerarquía d e clases n o
parece encajar adecuadamente c o n el problema, tenemos
que refactorizarla.
•
Clases abstractas → No se pretenden utilizar
para crear instancias y s u propósito
es servir exclusivamente como superclases d e otras clases.

•
Ventajas d e la herencia:
-
se evita l a duplicación d e código.
-
Reutilización del código.
S e facilita el mantenimiento → L a relación entre las clases está claramente
ex -
-
↳ U n cambio e n u n
campo o enun método compartidos
sólo tendrá que hacerse una vez.
-
Capacidad de ampliación.
•
subtipo→ los tipos forman u n a jerarquía de tipos.
↳ El tipo especificado por l a definición d e u n a subclase es u n subtipo del tipo
correspondiente a s u superclase.
•
E s posible usar u n objeto d e una subclase cualquier lugar en
que s e requiera el tipo
c o -
e n
a su superclase.
Variables l a s variables pueden almacenar objetos d e
y subtipos→ tipo declarado de
•
s u o
cualquier subtipo d e s u tipo declarado→ Principio de sustitución.
↳ El tipod e una variable declara qué e s lo que esa variable puede almacenar.
•
sustitución → Pueden utilizarse objetos d e u n subtipo e n cualquier lugar e n e l que l o
que s e espere s e a n objetos de u n

supertipo.
↳ l o que n o s e puede hacer es l o contrario.
• Variables polimórficas → Pueden almacenar objetos del tipo declarado o de cualquier
↳
subtipo del tipo declarado.
Son las variables almacenan tipos d e objetos.
que
°
Casting → Debe evitarse siempre que s e a posible → Puede conducir a errores e n tiempo
↳
d e ejecución.
Sustituir cast por llamadas a métodos polimórficos.

D e -
Vehicle v;
Car c = new Car();
v = c; //correcto c = (Car) v; //correcto
c = v; //error
✓
todos los c a r son no todos los
vehicle vehicle s o n c a r
°
Operador de cast → Está compuesto por e l nombre de un tipo escrito entre paréntesis
delante de una variable o una expresión.

•
Todas las clases que n o tienen una superclase explícita tienen a Object como superclase
↳ Esto tiene 2 objetivos:

↳ podemos declarar variables polimórficas d e tipo Object capaces de a l m a -
{ cenar cualquier tipo d e objeto.

l a clase Object puede definir algunos métodos estén
d i s p o n i -
que luego
>
automáticamente para todos los objetos existentes.

↳ métodos t o
string, equals y h a s hCode.

TEMA 11: MÁS SOBRE LA HERENCIA
• Podemos introducir u n texto d e v a r i a s líneas e n u n a cadena utilizando "In" e n la
cadena como salto d e línea.

•
El tipo estático de una variable ✓ es el tipo tal como está declarado e n e l código
fuente → en l a instrucción d e declaración d e l a variable.

•
Para l a comprobación d e tipos s e utiliza e l tipo estático.
E l tipo dinámico d e variable el tipo d e l objeto que estáalmacenado
a c ↳t u a l -
°
una v es
en v. tiempod e ejecución→
depende de l a s asignaciones del
c o m p o r t a -
e n
dinámico del programa.

↳ el tipodinámico sólo s e conoce e n tiempo de ejecución.
n o coinciden
exactamente e l
dinámico car
tipo
estáticop-tipo Vehicle.
}
Vehicle v1 = new Car(); El tipo d e l a variable v 1 e s
El tipo del objetoalmacenadoe n v 1 e s

•
sustitución d e métodos → U n a subclase puede sustituir l a implementación d e u n método.
¢
↳ l a subclase declara u n método con la misma signatura q u e l a superclase,
pero c o n u n cuerpo del método diferente.
e l método sustituto tiene precedencia e n las llamadas a método
efectuadas,.ae
los objetos de l a subclase.
• También s e llama redefinición.
•
L a anotación @Override puede añadirse antes d e l a versión e n l a subclase para dejar claro
nueva versión d e u n método heredado.
ques e está definiendo u n a
°
Los objetos d e l a subclase dispondrán d e dos métodos con el mismo nombre y la misma
c → auno
-
heredado d e l a superdase y otro d e l a subclase.
•
Búsqueda d e métodos→ L a comprobación d e tipos emplea e l tipoestático, pero e n tier
(asociaciónd e métodos o ejecutan l o s métodos correspondientes a l tipo
po d e ejecución s e
despachod e métodos)
dinámico.

•
Cualquier método que s e encuentre e n una superclase podrás e r invocado sobre u n objeto
d e l a subclase y e s e método podrá encontrar

y ejecutar
se correctamente.
•
Quien determina qué método se encuentra en primer lugar y se ejecuta e s e l tipodinámico,
n o el tipo estático. comienza

los métodos sustitutos d e las s u b
↳ L a búsqueda d e métodos c tienen
l aprecedencia -sobre los m i t o -
por l a clase dinámica d e l a instancia. dos d e l a superclase.
Sólo s e ejecuta l a ú l t i m a versión µ

( l a q u e e s t ám á s abajo e n l a jerarquía d e herencia)
•
Llamada a
super e n los métodos → cuando queremos que s e ejecute tanto e l método
de l a subclase como e l d e l a superclase.
r e[n t e s a d a
e n cualquier lugar dentro d e l
hay que public void display(){
método
enunciar
super.display();
System.out.println(“ [“ + filename + “]”); tu
explícitamente System.out.println(“ “ + caption);
n o tiene
e l nombre del } ques e r necesaria-
o
Mente l a primerainstrucción.
Método d e la
superclase es obligatoria n i s e genera automáticamente diferenc
a ia de l o s
constructores
°
E n ausencia del mecanismo d e sustitución d e métodos, los miembros no privadosd e u n a super-
clase s o n directamente accesibles desdes u s subclases s i n necesidad d e ninguna sintaxis
e → s p
solo e s necesario hacer u n a e llamada a
-
super cuando haga falta acceder a la
versión existente e n l a superclase d e u n método sustituido.

• Variable polimórfica→ aquella que puede almacenar objetos d e diversos tipos.
•
Polimorfismo d e métodos→ L a s llamadas a métodos e n Java s o n polimórficas.
↳ l a m i s m a llamada a método puede diferentes métodos
{Desp
invocar en
distintos momentos, dependiendo del tipo dinámico d e l a variable
acho para usada hacer dicha llamada.
d e métodos polimórficos.

•
Todo objeto e n Java tiene un método t ostring que puede utilizarse para devolver u n a
representación de e s e objeto en forma d e string.

↳ Para sustituirlo por u n a
{sueli
método deben
que este ú t i l , los objetos
m -
sea
propia.
e ser buena idea sustituir este método en nuestras propias clases.
°
Los métodos system-out.print s istem.out.printI n → s i el parámetro no e s u n objeto
y
automáticamente a l método tostring del objeto.
string, e l método invoca
°
E l método t ostring suele s e r útil para propósitos d e depuración.
•
Igualdad d e referencias→ N o tiene e n cuenta e n absoluto e l contenido d e los objetos.
↳ utilizando e l operador =
↳
s e comprueba
{Se
= .
Devuelve true si están haciendo referencia a l mismo objeto o s i ambas
son null.
limita comprobar s i objeto a l

hay u n único que están haciendo
r e f edistintas -
a
dos variables o dos objetos distintos.

•
Igualdad de contenidos→ Comprueba s i dos objetos s o n iguales internamente.
↳
↳
método equals.
Consiste e n verificar s i los valores d e los dos conjuntos d e campos s o n
iguales.
•
No siempre será necesario comparar todos loscampos d e dos objetos
para c o n c l u i r que s o n
iguales.
•
Siempre que s e sustituya e l método equals, e s necesario sustituir también e l método hashco.de
las estructuras HashMap y Hashs e t utilizan e l método hashCode para mejorar l a

e f i -
•
e n el almacenamiento
y l a búsqueda d e objetos e n e s o s tipos d e colecciones.
.
E l método hashcode devuelve u n valor entero que representa un objeto.
↳ los diferentes objetos tendrán valores hashcode distintos.

$ ! !
°
Acceso protegido→ protected→ Permite acceder a los campos o métodos situados
dentro d e la misma clase y también desde todas s u s subclases.
Declarar método protegido permite acceder directamente é l desde las

•
u n
campo o u n a
↳
)
s u bclases (directas indirectas). No
debili -
o se aplica a l o s campos porque
l a encapsulación.
métodos
Suele reservarse para
4
constructores.
y Loscampos mutables d e las superclases deberían
seguirsiendo privados.
°
L a herencia asocia las clases más estrechamente → cualquier modificación de l a super_
clase tiene m á s posibilidades d e hacer que l a subclase deje d e funcionar.

•
Nivel d e paquete→ nivel de visibilidad
que n o tiene asociado u n a palabra clave.
E l operador instanceo f → Comprueba s i objeto determinado e s , directa o
indi rectamente,
•
u n
↳ Cuando
una instancia d e u n a determinada clase.
necesitamos el tipo dinámico distintivo d e objeto,
averiguar u n
en lugar d e limitarnos a tratar con u n supertipo compartido.

devuelve true s i e l tipodinámico d e obj e s MyClass
obj instanceof MyClass
E
0 cualquier subclase d e MyClass.
operador derecho siempre e l nombre d e una clase.

l
es
E l operador izquierdo es siempre
u n a referencia a objeto.
•
La utilización del operador instanceof suele i r seguido inmediatamente por u n c a s td e l a
referencia a objeto, para transformarla e n e l tipo identificado.
-
ArrayList<MessagePost> messages = new ArrayList<MessagePost>;
for(Post post : posts){
if(post instanceof MessagePost){
messages.add((MessagePost) post);
}
}

TEMA 12: TÉCNICAS DE ABSTRACCIÓN ADICIONALES
•
Para mejorar l a s estructuras d e clases y para facilitar l a mantenibilidad y l a
a m p l i a b i -
• Simulaciones → Tratamos d e modelar e l comportamiento d e u n subconjunto d e l mundo real
¢
utilizando un modelo software.
Toda simulación e s una simplificación d e s u modelo real.

> Ventaja → Podemos realizar experimentos
que n o podríamos llevar a cabo con
e l sistema real.
t a m a -
°
Simulaciones predador-presa→ suelen utilizarse para modelar la variación e n los
d e l a población que resultan del hecho d e q u e u n a especie predadora s e alimente d e
otra especie que utiliza como presa.

↳ Tiene importancia económica y n o solo medioambiental,
Clases abstractas:
°
No están pensadas para crear objetos, s i n o solo para servir como superclases.
° Pueden contener métodos abstractos.
°
No pueden crearse instancias → N o tienen constructor.
° L a definición de un método abstracto está compuesta d e u n a cabecera d e método, s i n
que exista u n cuerpo del mismo.

µ >
s e marca con l a
S u cabecera termina
palabra clave abstract.
con u n puntoy coma.
•
Las clases que n o son abstractas s e denominan clases concretas.
•
Subclase abstracta → Para q u e u n a subclase d e u n a clase abstracta s e transforme
concreta, debe proporcionar implementaciones para todos los métodos abstractos

h e r e d a -
en
→ Si n o lo hace, l a propia clase será también abstracta.

° l o s métodos abstractos garantizan q u e todas las subclases concretas dispongan d e u n a
implementación d e dicho método.

° Podemos emplear u n a clase abstracta como tipo e n las formas habituales. (aunque n o podamos
crear instancias de ella).

↳ Aquellas partes de l a simulación q u e n o necesiten saber s i están tratando
subclase específica podrán usar e n s u lugar e l tipo
correspondien -
con u n a
a l a superclase.
Los campos e n Java s e gestionan d e forma distinta los métodos →

s u s t i t u i -
•
a n o pueden s e r
por versiones específicas de las subclases.

•
S e emplea el tipodinámico de u n objeto para determinar qué versión d e u n método s e invoca
tiempo de ejecución → cada instancia utilizará e l valor apropiado para tipo d e

s u b -
en s u
•
Llamadas a método en l a superclase → Las llamadas a método n o privadosdesde dentrod e
u n a superclase siempre s e evalúan en e l contexto m á s amplio del tipo dinámico del objeto.
• Herencia múltiple → Cuando tenemos u n a situación e n l a que u n a clase hereda d e
más d e una superclase. ↳ Java no permite la herencia múltiple d e clases.
1
que permite u n a forma ilimitada d e herencia
Pero proporciona otra estructura
{múltiple.
Interface →
• E s u n a especificación d e u n
tipo (en l a forma de u n nombre de tipa u n
c o n -
y
↳ Características:
d e métodos) que n o define ninguna implementación paralos métodos.
-
En l a cabecera d e l a declaración s e utiliza interface en lugard e class.
- N o contiene constructor.
-
No contiene campos d e instancio.
sólo s pueden definir campos d e clase constantes (static y

final) c o n
v ipublic.s i -
-
e
-
los métodos abstractos n o tienen q u e i n c l u i r abstract e n l a cabecera.

En las interfaces l a s palabras clave static,
final y public s e pueden o m i t i r
•
↳ se dan por hechas d e forma automática.

°
E n l a s interfaces pueden disponerse d e los métodos n o abstractos:
-
marcados con l a palabra default
→
y→ Ambos tienen u n cuerpo d e método.
-
señalados c o n la palabra s t a t i c
•
Todos los elementos d e u n a interfaz tienen visibilidad pública.
•
Para heredar d e u n a interface s e usa l a palabra implements.
↳ U n a clase implementa una interfaz s i incluye u n a cláusula implements e n
s u cabecera de clase.
•
Si una clase amplía a la vez otra clase e implementa u n a interfaz → l a cláusula
extends debe escribirse primero e n l a cabecera de l a clase.

•
Un método marcado c o m o default e n u n a interfaz tendrá u n cuerpo d e método, q u e es
heredado por todas las clases d e implementación → deja d e ser cierto que l a s interfaces
nunca contienen cuerpos d e método.

•
L a funcionalidad posible e n u n método pordefecto está limitado, estrictamente, dado
que n o
existe ningún estado manipular directamente.

que puedan e x a m i n a r
o
En general, a l escribir nuestras propias interfaces solemos limitarnos métodos puramente

^
a
abstractos.
°
J ava permite a u n a clase ampliar como mucha otra clase → pero s i permite que u n a
clase implemente cualquier número d e interfaces.
Cuando clase implementa múltiples interfaces y dos o m á s las interfaces
t i e -
°
u n a de
u n método por defecto con l a misma signatura → l a clase de implementación debe
sustituir a ese método → incluso si l a s versiones alternativas d e l método son idénticas.
•
L a cabecera del método d e sustitución n o contendrá l a palabra default.
para llamar a método por defecto desde las interfaces
°
super → u n u n a de e n u n método
de sustitución.

⑧
public void reset(){ Una c l a s e d e implementación que sustituye
Actor.super.reset();
Drawable.super.reset();
}
a u n método por defecto heredado puede
{ invocar a l método
pordefecto mediante l a
sintaxis:
InterfaceName. super.methodName l...)
-
•
Cuando u n a clase implementa u n a interfaz, n o hereda ninguna implementación d e e l l a
↳ porque las interfaces n o pueden contener cuerpos d e método.
U n a interfaz define tipo exactamente igual que l o hace clase pueden
d e -
•
u n u n a →
variables para q u e s e a n del tipo d e l a interfaz→ a u n cuando no puedan

existir objetos d e dicho
tipo.
↳ l a s interfaces no pueden tener instancias directas, pero s i r v e n c o m o super-
tipos
para l a s instancias d e otras clases.
l a característica m á s importante de las interfaces la

que separan completamente
d e f i -
•
e s
d e l a funcionalidad con respecto a su implementación.

•
E l paquete java-Util define e n forma de interfaces abstracciones d e colección
i m List,
p o r -
varias
como Map y set.

↳ Utilizando siempre que s e a posible e l tipoabstracto d e mayor nivel (ya sea u n a
clase abstracta o u n a interfaz) para nuestras variables, nuestro códigoseguirá
siendo flexible d e cara a futuros cambios en l a librería.
L a clase C l a s s :
-
No tiene n a d a q u e v e r específicamente c o n l a s interfaces→ e s u n a característica
g d eJava.
e -
-
Cada tipo tiene u n objeto class asociado c o n é l .
-
Otra forma d e obtener el objeto Class para u n cierto tipo consiste e n escribir".class"
detrás del nombre del tipo (Font.class a int-class).
-
Incluso los tipos primitivos tienen objetos class asociados.

-
L a clase Class e s u n a clase genérica→ tiene u n parámetro tipo que especifica el
subtipo d e clase concreto a l que hacemos referencia.

↳ El tipo d e string.class es Classe string>
Puede utilizarse signo d e interrogación lugar d e l parámetro tipo (Classe?d)s i

-
u n e n
s e desea declarar u n a variable que contenga todos los objetos d e clase de todos los
tipos.
los objetos class son

muy útiles s i deseamos saber si el tipo d e dos objetos coincide.
-
•
E s preferible definir métodos por defecto las interfaces salvo el
n o e n con fin d e adaptar
código antiguo.
°
S i podemos elegir→ las interfaces s o n preferibles → son tipos relativamente ligeros q u e
reducen a l mínimo las limitaciones sobre las clases d e implementación.
↳ s i proporcionamos u n tipo como clase abstracta → l a s subclases n o pueden

e xa otras clases -
↳ E l uso de u n a interfaz no impone d i c h a restricción.
•
Las interfaces distinguen claramente l a especificación del tipo d e l a implementación
↳ esto c r e a u n a m e n o r superposición.
• El uso de interfaces permite obtener u n a estructura m á s flexible y ampliable.
Las simulaciones basadas e n asíncronas suelen s e r m á s eficientes
y resultan
•
p r e -
sucesos o
cuando tenemos sistemas d e gran t a m a ñ o y

que tratar
c a n↳ t i -
con con grandes
d e datos. l a simulación s e dirige manteniendo u n a planificación d e
sucesos futuros.
l a s simulaciones de carácter temporal o síncronas
v i s utemporal,
a l i ztiempo
a fluye -
mejores para generar
•
s o n
de carácter porque e l de manera m á s uniforme.

TEMA 14: TRATAMIENTO DE ERRORES
•
Los errores lógicos son más difíciles d e detectar q u e los errores sintácticos.
• Los errores lógicos surgen porque:

-
L a solución a u n problema s e h a implementado d e forma incorrecta.
-
Puede que s e l e pidaa u n objeto hacer algo
que n o es capaz d e hacer.
-
Un objeto podría s e r usado e n
formas que n o hubieran s i d o anticipadas por
e l diseñador d e l a clase y q u e e s o
e s t a -
conduzca a
q u e e l objeto quede e n u n
incoherente o inapropiado.
Programación defensiva:
°
Un objeto servidor típico n o inicia por s u propia cuenta ningún tipo d e a c c i ó n .
↳ todas sus actividades están dirigidas por l a s solicitudes d e los
clientes.
° Varios puntos d e vista a l a h o r a de implementar u n a clase servidora:
÷::::::::::::::::::::::::::::::::..
medio
y
↳ solo solicitarán los servicios d e
definida.
u n a forma coherente y bien
probable
problemático → hay que adoptar todas l a s posibles m e d i d a s para impedir que
los objetos cliente utilicen e l servidor d e forma incorrecta.
-
Puede haber u n cliente intencionalmente hostil→ que esté intentando h a c e r
fallar e l servidor o encontrar u n a debilidad e n e l mismo.
• No estápermitido invocar ningún método para u n a variable que contenga u n "

↳ s e producirá u n error e n tiempo d e ejecución
↳ excepción NullPointerExcepción.
•
Cuando m á s vulnerable es u n objeto servidor es cuando s u constructor y s u s
métodos reciben valores externos a través d e s u s parámetros → e s crucial que
e l objeto servidor sepa si puede confiar e n l a validez d e los valores d e los p a -

rámetros o si necesita comprobar s u validez por s í mismo.
•
s i n o se comprueban l o s parámetros → se puede producir u n error fatal e n tiempo
d e ejecución.
Generación d e informes d e error:
E s conveniente problema
que e l servidor indique q u e s e h a producido u
•
n
↳ informando a l propio cliente, a u n usuario o a l programador.
1 . Notificación a l usuario:
°
L a forma m á s obvia e n l a q u e u n objeto puede responder c u a n d o detecta que hay u n
error es tratar d e notificar d e alguna m a n e r a a l usuario de l a aplicación
¢ >
imprimiendo
mostrando u
un
n
mensaje de
mensaje d e e r r o r
error utilizando
e n u n a
System. o u t
ventana d e alerta.
a System.e n
Problemas→ Presuponer
q u e l a aplicación e s t á siendo utilizada por u usuario h u m a n o
•
n
↳ que verá e l mensaje d e er ror.
Será r a r o que e s e usuario tenga l a posibilidad d e h a c e r algo para corregir e l
problema.
↳ Solo e n los c a s o s e n los

que l a a c c i ó n directa d e l usuario haya
c o n a
-
l a aparición del problema (como suministrar d a t o s n o válidos)
↳ Así el usuario puede tomar algún tipo d e acción correctora
l a próxima vez o , a l menos, evitar cometer e l mismo error.
°
L a notificación del error a l usuario n o e s u n a solución general a l problema d e l a
generación d e informes d e e r r o r → l a mayoría d e veces lo que hacen e s desconcertar
a l usuario.

2 . Notificación al objeto cliente:
que e l objeto servida envíe indicación a l objeto cliente cuando

•
Consiste en una
algo salga mal.

°
2 formas d e hacerlo:
Usando métodos tipo d e retorno distinto d e para devolver

f-
e n sus u n void
valor que indique e l método h a fallado
[--
un si no. o
Generando una excepción s i algo sale mal.

> Ventaja→ l a s dos. animan a l programador d e l cliente a tener e n cuenta q u e
l a llamada a un método puede fallar.

•
sólo l a excepción impide d e manera activa que se ignoren l a s consecuencias del
fallo de un método.
°
E s común que los métodos que devuelven referencias a objetos utilicen e l valor null
como indicación de fallo o error.
°
Los métodos que devuelven valores primitivos hacen l o m i s m o devolviendo u n valor
fuera d e limites.
↳ Esto no s e puede hacer cuando todos los valores del rango correspondiente
tienen u n significado válido para e l cliente.
↳ Aquí recurriremos a l a generación d e u n a excepción.

•
Problemas asociados al rito de valores de retorno como indicadores d e fallo o error:
No hay ninguna forma d e obligar a l cliente comprobar l a s

p rdiagnóstico
o pdel i deeretornod aE l -
-
a
de valor → cliente continuará como
s i nada hubiera sucedido y terminará con u n a MullPointerException o
utilizando e l valor retornado
l ó -
como un valor normal generando u n error
muy difícil de diagnosticar.

Podríamos estar usando el valor d e diagnóstico para dos propósitos
c o distintos.
m p l e -
-

•
E n muchos casos, Una solicitud sin éxito representará lógico d e
p r o -
no u n error
mientras que una solicitud incorrecta casi siempre lo representa.
Principios d e la generación d e excepciones:
Generar excepción l a forma más efectiva d e l a objeto

que dispone
•
s e r -
una es u n
para indicar que n o puede terminar una llamada a uno de sus métodos.
° Ventaja → E s c a s i imposible cliente ignore e l hecho d e que s h a generado

que u n e
{El
excepción
una
y continúe s u procesamiento como s i n a d a hubiera pasado.
↳ si e l cliente n o trata l a excepción, l a aplicación terminará

in -
de independiente del valor de retorno d e
m é -
mecanismo excepciones es u n
→ Puede utilizarse para todos los métodos.

E l lugar diferente d e aquel
que s e intenta
•
e n el que se descubre u n error e s e n el
de El será descubierta dentro del método del

s e r v i -
recuperarse e s e error → error
mientras que l a recuperación s e h a r á e n el cliente.

•
Una excepción e s u n objeto
que representa los detalles d e u n
fallo del programa. La
excepción s e
genera para indicar q u e se h a producido u n
fallo.
°
Hay dos etapas en el proceso de creación de u n a excepción:
t:) s e c r e a u n objeto excepción con n e w .
2) se envía el objeto utilizando throw.
-
public ContactDetails getDetails(String key){
if(key == null){
throw new IllegalArgumentException(“null key in getDetails”);
}
return book.get(key);
}

•
Cuando crea u n objeto excepción, puede pasarse u cadena d e diagnóstico
c o n s -
s e n a a s u
→ Esta cadena estará luego a disposición del receptor d e l a excepción a través
d e los métodos getMessage y tostring del objeto excepción.
↳ si l a excepción n o s e trata, l a cadena s e muestra también a l usuario y esto
conduce a l a terminación del programa.

°
IllegalArgumentException está en e l paquete java.lang
↳ se utiliza para indicar que s e h a pasado u n valor d e parámetro real
incorrecto a u n método o a u n constructor.

• L a documentación javado, de un método puede ampliarse para incluir detalles d e l a s
excepciones con e l marcador @throws.

que genere
•
Un objeto excepción e s u n a instancia d e u n a clase pertenece a jerarquía d e herencia
que u n a
especial.
H ↳ Podemos c r e a r n u e v o s tipos d e excepción creando subclases d e esta jerarquía.

• as clases d e excepción s o n siempre subclases de l a clase Throwable del paquete java.lang.
↳ Por convenio, usaremos subclases d e l a clase Exception d e
java.lang.
' E l paquete MullPointerException,
java.lang define unas clases d e excepción comunes como
IndexOutOfBoundsException y ClassC a s tException.

•
J ava divide las clases d e excepción e n dos categorías:
-
Excepciones comprobadas → Es un tipo d e excepción requiere comprobaciones
cuyo uso
adicionales por parte del compilador. Requieren e l
i try.
n ↳s t r u c c i o -
uso de cláusulas throws e
s o n todas las clases restantes de Exception (quitando las subclases
de l a clase estándar RuntimeException).

Excepciones n o comprobadas → Es tipo de excepción
u n
requiere ninguna
-
cuyo uso n o
comprobación
por parte del compilador.
↳ son todas las subclases de la clase estándar RuntimeException.

!%!
• Exception es una d e las dos subclases directas de Throwable, l a otra es Error.
• Las subclases de Error suelen estar reservadas para los errores del sistema d e tiempo
de ejecución, más que para errores sobre los cuales e l programador tenga control.
0 clasesde l a librería estándar

0 clases definidas pore l usuario
*
**
Y Timeexcept
PMicepincomprobada
ion
Y
MitxcepcionNocomprotado
•
l a s excepciones comprobadas están pensadas
para aquellos casos en los que e l cliente
debería esperar una operación pueda fallar→ E l cliente estará obligado a comprobar
que
si l a operación h a tenido éxito.
•
Las excepciones n o comprobadas están pensadas para aquellos casos
que n u n c a deberían
fallar durante l a operación normal → indican u n error del programa.

•
Reglas para saber qué categoría d e excepción
generar:
Usar excepciones comprobadas
para las situaciones que deberían conducir
-
no a u n
fallo del programa porque s e sospecha que existe algún error lógico dentro del
programa que le impedirá continuar haciendo s u tarea.
↳ Las excepciones comprobadas deberían emplearse cuando el cliente

p llevar u a cabo u n a
e
recuperación. -
-
Emplear excepciones comprobadas
para las situaciones que pudieran
r a z evitadas.
o n a -
no
ser
↳ Las excepciones comprobadas deberían utilizarse para aquellas

situaciones de fallo fuera del control del programador.
que caen
E n Java, l a s reglas formales d e las excepciones

que gobiernan e l
s i g n i f i c a t i va -
•
uso son
distintas para las excepciones comprobadas y las n o comprobadas.
↳ Esas reglas garantizan objeto cliente método que pueda

que un
que invoque u n
excepción comprobada siempre contendrá código la
p oque surja
s i -
generar una
que prevea
y que intente tratar e l

de u n problema problema e n caso de
que este se produzca.
cuando
i n m e d tipoi a t a -
genera excepción, l a ejecución del método actual finaliza
•
s e u n a
los métodos d e retorno distinto d e void
e j e -
→ con u n no estarán obligados a
una instrucción d e retorno a l generarse l a excepción.

↳ La
{
generación d e l a excepción indica l a incapacidad d e este método
para continuar con s u ejecución normal→ esto incluye n o s e r capaz
d e devolver u n resultado válido.

+
l a ausencia d e u n a instrucción d e retorno e n l a ruta d e ejecución que termina
generando una excepción e s aceptable → e l compilador indicaráerror s i s e
escribe cualquier instrucción después d e una instrucción

throw.]
porquen u n c a podría llegar
a ser ejecutada
•
E l efecto de la excepción sobre e l punto del programa
en el que s e h a invocado e l método problemático dependerá d e si se ha escrito o no
algún código para captar la excepción.

↳ s i no se captura, e l programa terminará, con u n a indicación de
que s e
h a generado una excepción IllegalArgumentException n o capturada.

Utilización de excepciones no comprobadas:
°
S o n las m á s fáciles de utilizar → e l compilador impone muy pocas reglas.
°
E l compilador n o aplica ninguna comprobación especial n i e n e l método en e l que se
excepción n i e l lugar desde e l que dicho método ha sido invocado.

genera l a en
°
Una clase excepción es no comprobada si es u n a subclase d e RuntimeException,
del paquete java.lang.

°
Basta con emplear l a instrucción throw.
°
Por convenio, deben emplearse excepciones n o comprobadas e n las situaciones en las
que el resultado esperado sea l a terminación del programa.

°
s i existe l a necesidad d e capturar u n a excepción no comprobada→ puede escribirse
una rutina d e tratamiento de excepción adecuada→ igual que e n l a s excepciones
comprobadas.
Merece l a
pena que los métodos realicen serie d e comprobaciones d e validez sobre
°
u n a
sus parámetros antes de continuar con e l propósito principal del método.

°
E l método estático require NonNull de l a clase java.Util.Objects proporciona u n atajo
para verificar u n a expresión
y generar
u n a excepción s i l a expresión e s null.
↳ generará u n a excepción NullPointerException s i e l valor d e Key e s
null.
"null Key passed t o
getDetails");
Objects. requireHornbill (Key,
°
Un uso importante de las excepciones es impedir que s e creen objetos si estos n o
pueden colocarse e n un estado inicial válida.

↳ Consecuencia de constructor valores d e parámetro
i n ↳a p losr o p i a -
pasar a u n
En constructores l a s excepciones s e
generan igual
los métodos.
que en
diente.]
También tendrán e l m i s m o efecto sobre el

Tratamiento de excepciones:
solo e s obligatorio laslexcepcionesÜÜonduf

•
con
ase de Exception peron d e Runtime

E x c e p -
o
cuando utilizan excepciones comprobadas, hay que seguir v a r i a s reglas más, porque e l
•
s e
compilador impone unas comprobaciones tanto en e l método q u e genera l a excepción
c o m como e n todos aquellos -

que invoquen a dicho método.
↳ t.tn método excepción comprobada debe declarar que l o hace
¢,,,,,,,,,@µ,,,,,,,,,
que genere u n a
mediante una cláusula throws añadida a la cabecera del método.
Ej:
~ public void saveToFile(String destinationFile)
throws IOException
,,,,,,,,,,,,,,,,,
l a cláusula
c o m p i l a -
•
se puede usar throws para l a s excepciones n o comprobadas, pero e l
no lo exige.
1 E l llamante d e u n método que genere u n a excepción comprobada debe tomar
medidas para tratar con esa excepción.
↳ Escribir una rutina d e tratamiento d e excepciones e n l a forma d e
instrucción try. ↳ bloque try

y bloque catch.
::::::::::::::::::::::::::::::::::
""
excepción s e denomina rutina de tratamiento d e excepción. Proporciona código para in-
-
En u n bloque try puede incluirse cualquier número d e excepciones → colocaremos a l l í
solo l a instrucción que estén

r e l a -
n o
que puede faltar sino también todas aquellas
con ella.
•
Un bloque try representa una secuencia de acciones que queremos tratar como u n a
sola unidad lógica, reconociendo

que
puede
fallar e n algún momento.

•
El bloque catch intentará tratar con l a situación que se h a producido o informar
acerca del problema, s i se genera alguna excepción a l ejecutar cualquiera d e l a s
instrucciones del bloque try asociado.
°
Las variables que s e u s e n en los bloques try y catch tendrán que declararse fuera
de l a instrucción try.
°
Una excepción impide que continúe en el llamante el flujo normal d e control.
↳ s i s e genera u n a excepción
por u n a instrucción i nvo c a d a dentro del bloque
try, l a ejecución se reanuda en e l correspondiente bloque catch.
•
Las instrucciones contenidas e n u n bloque try s e llaman instrucciones protegidas.
excepción durante l a ejecución del saltará a l bloque
•
s i n o
surge ninguna bloque try, s e
catch tras alcanzarse e l final del bloque try → l a ejecución continuará con lo que
haya después d e l a instrucción try)catch completa.

°
Un bloque catch indica e l tipo de excepción
para e l que está diseñado.
↳ Además del nombre del tipo d e excepción, también incluye un nombre d e variable
(e o ex) para hacer referenciaa l objeto excepción generada

>
Una v e z completado el bloque catch, e l control vuelve l a instrucción q u e h a
p r o -
no a
l a excepción.
°
Encer rar u n a instrucción throw directamente dentro d e u n a instrucción try será c a s i seguro u n
CHOI.
°
S i u n método genera m á s d e un tipo d e excepción → s i s o n excepciones comprobadas, hay
que enumerarlas todas en l a cláusula throws del método, separadas por c a m a s .
Ej:
÷ public void process()

throws EOFException, FileNotFoundException
Una rutina d e tratamiento de excepciones debe gestionar todas las excepciones

c o mpartir p r o b a -
°
generadas protegidas instrucción

a de s u s instrucciones → una try puede
contener varios bloques catch
o b -
→ Puede usarse e l mismo nombre de variable para e l
excepción e n todos los casos.

•
Cuando llamada a método dentro d e bloque try genera excepción, s e
c o m p r u e -
una u n una
los bloques catch en el orden e n que aparecen escritos, hasta que s e encuentra u n a
correspondencia con el tipo de excepción → cuando termina el bloque catch, l a

e j e c
continúa después del último bloque catch. u -
Puede usarse polimorfismo bloques catch.
para evitar tener que escribir múltiples
•
↳ Pero esto puede hacer

que n o sean capaces de llevar a cabo acciones d e
recuperación específicos
para cada tipo de excepción.
°
El orden de los bloques catch dentro de una misma instrucción try e s importante.
°
Ningún bloque catch
para u n
determinado tipo de excepción puede estar situado después
del bloque correspondiente a u n o de s u s supertipos → si lo hacemos e l compilador

dará e lr o l .
•
Para gestionar múltiples excepciones con l a misma acción d e recuperación o información:
j '
try {
...
ref.process();
...
}
catch (EOFException | FileNotFoundException e){
//Llevar a cabo una acción apropiada para ambas excepciones.
...
}
•
Las excepciones deben capturarse y tratarse en l a primera oportunidad disponible.
Es ↳ U n a excepción generada e n un método denominado process debería s e r

capturada y tratada e l método que haya llamado a
to
e n process.
hace Java permite que excepción s e a propagada

•
no siempre s e así→ u n a
desde el método cliente →

r u t i -
para ello e l método s e limita a no incluir u n a
de tratamiento d e excepciones que proteja l a instrucción que puedegenerar

esa excepción.
→
•
Para las excepciones comprobadas e l método que está propagando l a excepción
debe incluir l a cláusula throws (aunque n o cree

y envíe él mismo l a excepción).
↳ Es frecuente encontrar métodos cláusula throws pero

n i n g u -
con c o n
instrucción throw dentro del cuerpo del método.

°
L a propagación se usa cuando el método hace l a invocación n o puede no
que o
necesita hacer ninguna recuperación por s í mismo, pero esa recuperación s í puede ser
posible 0 necesaria en otras llamadas d e mayor nivel.

↳ E s común e n los constructores.
S i l a excepción comprobado → l a cláusula throws
que s e está
°
propagando es del tipo n o
es opcional.
l a cláusula opcional → omite.

finally e s a menudo
-
s e
↳ incorpora l a s acciones preciso ejecutar independientemente d e

que e s
si s e h a generado una excepción o no.
E s posible omitir los bloques catch instrucción bloque

try que try
°
e n u n a tenga de
y de cláusula finally, si e l método está propagando todas las excepciones.

°
Cuando las clases de excepción estándar describan satisfactoriamente l a
n a t u r adefinir -
n o
d e s -
de una condición de error, s e pueden nuevas clases d e excepción m á s
usando l a herencia.
↳ Las comprobadas como subclases de Exception,por ejemplo.
Las n o comprobadas c o m o subclases de RuntimeException.
"
Para realizar pruebas d e coherencia internas eficientes, activadas
que puedan ser en
e l código durante el desarrollo, pero desactivadas e l código que s e libere

c o m e r c i a l -
en
→ Funcionalidad de aserción.
°
U n a aserción e s u n enunciado d e u n hecho que debe s e r cierto durante l a ejecución del
programa. Podemos utilizar aserciones para anunciar explícitamente nuestras suposiciones y

para detectar m á s fácilmente los errores d e programación.
•
l a palabra clave assert va seguido por expresión booleana → propósito e s
e n u n punto del -
u n a s u
algo que debe ser cierto e n ese método.
Eji-neeee.ae
public void removeDetails(String key){
if(key == null){
throw new IllegalArgumentException(
“Null key passed to removeDetails.”);
}
if(keyInUse(key)){
ContactDetails details = book.get(key);
book.remove(details.getName());
book.remove(details.getPhone());
numberOfEntries—-; estepunto.
}
assert!keyInUse(key);
assert consistentSize(): “Inconsistent book size in removeDetails”;
}
↳ formaalternativa → l a cadena s e pasaráa l constructord e AssertionError para proporcionar
u n a cadena d e diagnósticos puedeemplearse cualquier
tipodevalor,que
Una será transformado e n stringantesd e
°
instrucción d e aserción tiene dos objetivos. pasar.
glides"
"in
A) Expresar d e explícita l o
d e t e r m i -
manera
que asumimos " u n punto
de l a ejecución, incrementando a s í l a legibilidad para e l desarrollador

actual programadores de mantenimiento.
y futuros
2) Realizar l a comprobación e n tiempo d e ejecución → seremos notificados s i
muy útil para localizar

nuestra suposición es incorrecta→ errores e n u n a
fase temprana y con

mayor facilidad.
•
si l a expresión booleana de l a instrucción de aserción es true n o tiene ningún efecto ulterior.
Si s e evalúa como false s e generará u n error AssertionError → subclase d e E r r o r
↳ representa los errores irrecuperables.
los clientes n o deben proporcionar ninguna rutina de tratamiento. e )

•
Las aserciones suelen hacer u s o d e uno de los métodos existentes dentrode l a clase.
•
Puede ser útil proporcionar método e l objetivo específico de realizar prueba d e
a s e r -
u n con una
°
l a s aserciones están pensadas modo d e realizar pruebas de coherencia
para proporcionar u n
durante el desarrolloy pruebas d e u n proyecto → n o están pensadas para utilizarlas e n el

código final para uso comercial → los compiladores Java sólo incluirán l a s instrucciones
d e aserción e n el código compilado si s e les pide que lo hagan.

Las instrucciones de aserción deben usarse
para implementar l a funcionalidad normal.
•
nunca
Recuperación de errores:
E l primer requisito clientes tomen nota de cualquier notificación de e r r o r

que los
°
e s
que reciban.
→
La instrucción try es l a clave para suministrar u n mecanismo d e recuperación d e
errores cuando s e genera u n a excepción.

↳ implicará llevar a cabo algún tipo de acción correctora dentro del bloque
catch y luego volver a intentar l a operación.

↳ pueden realizarse intentos repetidos incluyendo l a instrucción
try dentro de u n bucle.

Anticiparse é l requerirá u flujo d e control m á s complejo
°
a u n error
y recuperarse de n
e s e error n o s e puede producir.

que s i
Las instrucciones del bloque catch fundamentales para e l intento d e
r e c u p e r a -
°
son
°
l a recuperación implicará a menudo tener que intentar l a operación d e nuevo.
°
No puede garantizarse l a adecuada recuperación e n caso de e r r o r.
Debe haber alguna ruta de escape q u e impida reintentar eternamente

r e c u -
•
u n a
imposible.
Entrada/ s a l i d a basada e n archivo:
E l paquete fundamental relacionado l a s clases d e entrada/salida java.io.

•
con es
contiene muchas clases

para soportar operaciones d e a)
{entrada/salida independiente d e l a
de manera plataforma.
Define l a clase d e excepción comprobada 1 0Exception como indicador general d e
que algoha ido mal en una operación de entrada/salida.

°
E n versiones m á s recientes d e Java se está produciendo u n a migración desde u n a serie
de clases del paquete java.io a las d e l a jerarquía javanica.

princi
Dos categorías pales - 7 l a s que tratan c o n archivos d e texto.
→ l a s que manejan archivos binarios.
Las clases d e Java dedicadas a l procesamiento d e

l e c -
°
archivos d e texto s e conocen c o m o
escritores. ↳ las gestores d e flujos.

y que manejan archivos binarios son
°
L a clase File permite a u n programa consultar los detalles relativos a u n archivo externo,
de forma independiente del sistema d e concreto sobre e l q u e esté
e j e c u -
una archivos s e
el programa.
E l nombre del archivo constructor d e File.
pasa a l
°
s e
°
Al c r e a r un objeto File dentro d e u n programa n o s e crea e l archivo dentro d e l sistema
d e archivos, lo que hace e s

que s e almacenen en e l objeto File los detalles acerca
de archivo, s i archivo externo existe.

u n e s
que ese
°
L a interfaz Path y l a clase Files e n
javanio.file cumplen u n papel similar a File.
Podemos evitar situaciones objeto F i l e
que requieran t r a t a r excepción usando u
•
u n a n
o u n objeto Path para comprobar s i u n archivo existe o n o .
Un objeto File tiene los métodos exists intentar abrir

y cantead que hacen que e l
'
u n
archivo tenga menos probabilidades d e fallar si primero utilizamos esos métodos.
L a clase Files tiene muchos métodos estáticos

para investigar los atributos d e
°
u n
objeto Path.
P a r a escribir texto habitual objeto FileWriter, cuyo constructor

°
u n archivo d e es crear u n
acepta e l nombre del archivo v a escribir.

que s e a
↳ e l nombre del archivo puede estar como objeto string u objeto File.
°
Crear u n F i l eWriter abre e l archivo externo y l o prepara para recibir u n a información d e
salida → si a l intentar abrir e l archivo falla, e l constructor genera una I O Exception.

! $
Cuando e l abierto, pueden utilizarse los métodos write del escritor para almacenar
°
archivo e s
caracteres e n e l archivo.
una.mx#aiai*mi"""
•
"
"
try con recurso o gestión - existe u n a versión d e l a instrucción try que simplifica
de recursos automática
RM). ↳ para los
objetos d e las clases
sólo que implementen l a interfaz
Autoclaseable d e
java.lang.
" ÷
public boolean createFile(String filename, int numEntries){
boolean success = false;
try(FileWriter writer = new FileWriter(filename)){
se omite la creación de la entrada
for(int i = 0; i <= numEntries; i++){
writer.write(entries[i].toString());
writer.write(‘\n’);
}
success = true;
}
catch(IOException e){
System.err.println(“There was a problem write tiene to “ + filename);
}
return success;
}
Entrada d e texto:
° La clase FileReader contiene u n método para leer u n único carácter, pero n o
para l e e r u n a
línea. ↳ s u método read devuelve c a d a carácter c o m o u n valor int e n vez de
↳
COMO chal.
E s mejor trabajar con l a clase ButteredReader que tiene e l método readl i n e .

°
Un BufferedReader s e crea con e l método estático BufferedReader
n e w d e l a clase
Files.
°
L a c l a s e Scanner d e l paquete javaintil e s t á diseñada p a r a a n a l i z a r sintácticamente
e l texto y convertir secuencias compuestas d e caracteres e n valores con u n determinado
nextI n t para enteros, n ex D

tipo → t ouble para números e n c a m a flotante.
•
Análisis sintáctico → identificación de l a estructura subyacente.
• Escaneo → descomponer l o s caracteres individuales e n valores d e datos separados.

°
Aunque u n Scanner puede usarse
para descomponer objetos string, también s e u s a
directamente e l contenido de archivos

para leer y convertir de u s a r Buffered
R ↳ e a -
e n vez
T i e n e constructores
que pueden a d m i t i r argumentos de tipo string, File o
Path.
°
También s e u s a scanner
para leer la entrada desde e l "terminal" conectado a u n programa.
°
System-out e s d e tipo
java.io.Prints t r e a m → destino d e salida estándar.
•
system.in es d e tipo java.io.Inputstream → origen de entrada estándar.
°
C u a n d o hace falta leer entrada del usuario desde e l terminal, n o s e u s a directamente
u n Inputstream porque suministra l a entrada d e carácter e n carácter.

↳ lo que s e hace e s pasar system.in a l constructor de u n scanner.
- Scanner reader = new Scanner(System.in);

String inputLine = reader.nextLine();
°
E l método nexttime de scanner devuelve l a siguiente l í n e a completa d e entrada desde l a
entrada estándar → s i n incluir e l carácter final de a v a n c e d e línea.
Serialización:
•
L a serialización permite leer escribir e n ú n i c a operación objetos completos, a s í
y u n a como
jerarquías d e objetos→ Todos los objetos implicados deben pertenecera alguna clase que
implemente l a interfaz Serializable.
°
La serialización permite escribir u n objeto completo e n u n archivo externo e n u n a única
operación de escritura leerlo posteriormente mediante u n a ú n i c a operación d e lectura.

y
•
Funciona con objetos simples multicomponentes (colecciones).
y
E v i t a tener
que leer y escribir objetos campo a
•
campo.
• Es útil e n aplicaciones que dispongan d e d a t o s persistentes → libretas d e direcciones o
bases de datos d e información multimedia → permite que todas las entradas creadas en
una sesión s e guarden y se lean después en u n a sesión posterior.

•
L a clase del objeto a serializar debe implementar l a interfaz serializable d e l paquete
java.io. esta interfaz n o define ningún métodoa)

.
E l proceso de serialización es gestionado automáticamente por e l sistema d e tiempo d e
ejecución
y requiere escribir muy poco código definido por e l usuario.
Resumen:
Las excepciones impiden el

que cliente limite ignorar e l
°
s e a problema animan a los
y
programadores a tratar d e encontrar formas alternativas de actuación como solución
a los problemas, s i algo sale m a l .

s
A l desarrollar clase, pueden utilizarse instrucciones d e aserción para tener
c o m
u n a
-
internas d e coherencia → estas instrucciones s e suelen o m i t i r e n e l código de
producción.
•
l a entrada/salida e s u n área e n la que hay bastante probabilidad de que s e generen
excepciones.
•
l a API d e Java soporta l a entrada/salida d e datos tanto d e texto como binarios,a
través de lectores, escritores y flujos de datos.
°
los paquetes javainio sustituyen a las antiguas clases java.io.

Resúmenes POO Rigago PDF

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Resúmenes POO Rigago PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Resúmenes POO Rigago PDF

Cargado por

Copyright:

Formatos disponibles

!!!

TEMA 1: OBJETOS Y CLASES

creados s e llama banco d e objetos(object bench).

S i invocamos u n método, los objetos normalmente llevan a cabo u n a acción.

tarea. ↳ Pa r a cada parámetro s e define u n tipo y u n nombre.

/ para invocar dicho método.

Blue]→ E l estado de u n objeto puede inspeccionarse seleccionando l a función Inspecte n el

menú emergente del objeto. → Inspectord e objetos (object inspector).

campos almacena dos

Resúmenes POO Rigago 1 de 74

dentro d e una clase, n o en u n objeto.

tendrán los mismos métodos.

utilizando l a tecla flecha hacia arriba.

Invocación d e métodos → l o s objetos pueden comunicarse entre s í invocando

• E l código fuente d e una clase determina l a estructura y e l comportamiento (los campos

Resúmenes POO Rigago 2 de 74

tipo d e parámetro e l nombre de l a clase del objeto esperado.

dato que devuelve e s e método los modificadores del método (public,

Resúmenes POO Rigago 3 de 74

Una parte interna→ L a q u e hace todo e l

en e l momento d e crearlo primera v e z .

Campos → Almacenan datos q u e objeto tiene

↳ s e conocen también como variables d e instancia

entre Ixe y * / → comentarios de varias líneas.

como los campos pueden almacenar valores también

Resúmenes POO Rigago 4 de 74

crearlo por primera v e z → Inicialización.

acceder a esa variable.

l a variable antes d e ser destruida.

instrucción en la variable especificada a l a izquierda. expret

c r e a r espacio adicional de variables temporales.

'Métodos matadores → cambiar el estado de u n objeto. → setters.

Resúmenes POO Rigago 5 de 74

de una prueba a comprobación.

en una instrucción condicional.

Una variable local aquella que h a sido declarada u n único método.

S u ámbito su tiempo d e vida están limitados los del propio método.

momento d e declararlas. → Debeninicializarse antes d e poder s e r utilizadas e n u n a

Blue] Cuando e l resultado d e u n a expresión e n e l CodePad objeto, estará marcado

c o n u n pequeño símbolo d e objeto.→ Puede hacerse doble clic sobre é l

Resúmenes POO Rigago 6 de 74

l a atención e n un nivel superior d e u n problema.

↳ Dividimos u n problema complejo e n subproblemas sucesivamente hasta que cada

problema individual sea suficientemente pequeño poder resolverlod e manera

construirse examinarse por separado y que interaccionen d e formas bien definidas.

[Modularización divide grandes problemas e n partes m á s pequeñas.

l a declaración de otra variable d e

u n objeto d e ese → E l campo inicialmente está vacío.

E l diagrama de objetos muestra instante

Resúmenes POO Rigago 7 de 74

ejecución y presenta u n a vista dinámica d e u n programa.

la variable → l o que l a variable contiene es una referencia al objeto.

que aparece la referencia →

"Blue] → sólo proporciona l a vista estática.

'tipos primitivos→ Son los tipos

Están predefinidos en Java.

"Tipos d e objeto → Están definidos mediante clases.

Resúmenes POO Rigago 8 de 74