Anda di halaman 1dari 10

Desarrollo de Funciones en el Sistema Informático

Curso 2008/2009

Programación orientada a objetos (y II).


Orientaciones didácticas

 Parte teórica
 Parte práctica
 Base de conocimiento (alias preguntas más frecuentes)

Quincena 10. Orientaciones didácticas Página 1 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

Parte teórica
Con el tema 10 finalizamos el estudio de los principios básicos de la programación orientada a
objetos: trataremos la herencia y el manejo de excepciones.

El tema de la herencia corresponde al apartado 5.7 del material que utilizamos. En este tema
se estudia la herencia y el polimorfismo. No os asustéis, se les dan nombres "extravagantes"
para que parezca algo difícil de entender. Pero con la base que tenéis de SGBD (de nuevo)
tenéis casi todo el camino recorrido.

El concepto de herencia lo habéis tratado en SGBD en lo que allí se denomina


especialización/generalización (entidad/superentidad/subentidad). La idea es la misma: existen
una serie de elementos que heredan características de elementos "padre" y que tienen algunas
especiales propias. En SGBD esos elementos son las entidades y en DFSI son las clases.
Durante esta semana pondré algo en el blog sobre esto, seguidme la pista.

No quiero complicaros con conceptos más "fuertes", así que el apartado 5.7.6 (interfaces) no
lo leáis. Sólo para el que le interese, comentar que es la manera que Java puede hacer
herencia múltiple, es decir, que una clase herede características de "varios padres".

El tema del manejo de excepciones se trata en el apartado 7 (excepciones) del material


complementario "curso de Java". Veréis cómo la gestión de errores se controla
automáticamente por Java y para ello simplemente tenéis que introducir un par de líneas para
que funcione. Y con algunas líneas más, podéis hacer un control exhaustivo añadiendo
vuestros propios mensajes de error.

NOTA:

Por si no os gusta/os queda corta la explicación de la herencia, también podéis mirarlo en el


apartado 6.4 de este material complementario.

Ya adelanto que este es un tema mucho más suave que el anterior.

Os deseo un buen estudio.

Quincena 10. Orientaciones didácticas Página 2 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

Parte práctica
La décima Prueba de Evaluación Quincenal del módulo es una práctica dividida en dos partes.

1. La primera parte trata la herencia. Debéis crear dos nuevas clases que son heredadas
(extienden) la clase Equipo. Estas clases tienen atributos propios y sobrecargan el
método toString() para visualizar todos esos atributos.

2. La segunda parte trata el manejo de excepciones. Simplemente debéis tratar los


posibles errores para que aparezcan vuestros propios mensajes.

Recordad que para acceder a la evaluación cuatrimestral, la entrega de todas las PEQs es
obligatoria (y cada una de ellas debe tener una nota superior a 2).

Quincena 10. Orientaciones didácticas Página 3 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

Base de conocimiento
De Anónimo:
Hola,
espere que anaren bé les vacances, continuant amb la feina, a la pràctica 10 hem de treballar amb les
excepcions, no estic molt segur quines excepcions por llançar aquesta aplicació, algun suggeriment?
O és suficient capturar totes les excepcions (Exception) i mostrar un missatge personalitzat per a cada
metode?

Salutacions

De Anónimo:
Per cert, és necessari controlar excepcions en els setters, que tan sols assignen una variable?

De Cristian Jorge Garcia Marcos:


No, únicament es pot controlar una excepció en el cas de la crida a un mètode que llance
excepcions o bé perque nosaltres volem llançar les excepcions de manera expresa.
En un mètode on únicament s'assigna una variable no hi ha cap excepció a controlar.

De Cristian Jorge Garcia Marcos:


Hola,

Doncs les vacances han anat molt bé, gràcies. Espere que a vosaltres també us haja anat bé.

Respecte el tema del treball amb les excepcions, heu de capturar totes les excepcions possibles. Pots
mostrar un missatge personalitzat o simplemet mostrar el missatge de l'excepció (en cas de que ja
estiga definida). En tot cas, hi ha dues variants d'excepcions que heu de controlar:

- Les excepcions que ja estan definides en els mètodes dels paquets dels quals feu ús. És a dir, en el
vostre cas, feu ús, per exemple, dels mètodes de la clase List. En cadascun d'aquests mètodes ja hi ha
definides excepcions que poden ocòrrer i són aquestes les que heu de controlar.

- Les excepcions pròpies del nostre problema. Aquestes apareixen per la semàntica de l'enunciat. Les
podeu comentar en un fil nou del fòrum per saber si es significatiu o no incloure una o una altra en el
codi. Per a mostra, us indicaré una: no pot existir un equip amb dos números de sèrie iguals. I, què
implica això? Això implica que en l'alta d'un equip o/i l'actualització del número de sèrie es llance una
excepció en cas que un altre equip tinga el mateix número de sèrie.

Amb això, ho tens més clar?

Salutacions,

Cristian.

De Anónimo:
Sí, ja està més clar.
De moment tinc les excepcions degudes a IndexOutofBounds de List, i vaig a crear un nou fil per a
discutir les possibles excepcions a llançar per la nostra aplicació.

Anónimo

Quincena 10. Orientaciones didácticas Página 4 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

De Santiago Tur Querol:


En la clase torre para acceder al estado del status, tengo la opción de cambiar el modificador en la clase
Equipo, de private a protected, pero si no es así no se como acceder a status. Se me había ocurrido a
través de fechaBaja, pero no consigo averiguar como.
Una ayudita por parte de alguien?
Saludos,
Santi

De Santiago Tur Querol:


Hola creo que lo he solucionado. He sustituido if(!status) por if(super.getFechaBaja().isSet(0)), si no
es así, que alguien me diga algo.

Saludos,

Santi.

De Cristian Jorge Garcia Marcos:


Esta última opción que propones no es válida.

De Santiago Tur Querol:


Entonces, seria valido ponerlo en protected?

Gracias,

Santi.

De Cristian Jorge Garcia Marcos:


Esa es una opción y uno de los motivos por los que se creó protected.

¡Venga, que la práctica ya es vuestra!

Saludos,

Cristian.

Quincena 10. Orientaciones didácticas Página 5 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

De Anónimo:
Una proposta de possibles excepcions a llançar:

1. Si al comprovar que un numero de serie ja existeix al modificar o donar d'alta un equip es llança una
excepció.

2. Al intentar donar de baixa un equip ja donat de baixa anteriorment.

Crec que aquestes dues són les més importants, però seria necessari controlar, per exemple que el
format de la data introduïda és correcta?
o altre referents al format de les variable, com per exemple, que CodigoServicio sols fora "secundaria,
cicles..."

De Cristian Jorge Garcia Marcos:


Els dos punts que proposes són excepcions a controlar correctament.

Però les altres ja no ho són, fixa't que les altres dues ja no estan relacionades amb què interacció
(quines accions) realitza l'usuari, sinò de quina manera (com interactua) ho fa.

Això - una vegada més - s'ix dels objectius del mòdul. De totes maneres, si teniu interés, podeu
consultar-ho en Internet, en el que s'anomenen asercions.

Salutacions,

Cristian.

De Santiago Tur Querol:


Hola Cristian,
Por lo que comentáis para este ejercicio no hay que utilizar try, hay que crear las excepciones, por
lo que explicas en el blog, hay que crear una subclase con la excepción?
podrías poner un ejemplo práctico?, o explicar algo mas.

Saludos,
Santi.

De Santiago Tur Querol:


Rectifico, tenemos que crear nuestras propias excepciones, para ello hay que crear una nueva
clase para cada excepción? Y sigo con lo del ejemplo práctico, y ampliar el material.
Saludos,
Santi.

De Cristian Jorge Garcia Marcos:


Hola Santi,
La parte de las excepciones en la práctica se subdivide en dos apartados:

1er apartado. Captura de las excepciones en las llamadas a métodos de la API. En este
apartado, simplemente has de comprobar qué llamadas haces en tu código a la API (p.e. a
métodos de List) que pueden devolver excepciones. Una vez las hayas encontrado, debes
capturarlas y mostrar un mensaje de error.

2o apartado. Creación y captura de de excepciones de usuario. Además de los métodos de la


API que pueden causar excepciones, también existe código en tu programa que puede causar
excepciones y que no está controlado. Por ejemplo, nadie impide a un usuario crear un

Quincena 10. Orientaciones didácticas Página 6 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

nuevo Equipo en el Inventario con el mismo número de serie, pero esto no debería suceder,
así que se debería ejecutar una excepción. Estas excepciones definidas por el usuario son las
que estamos comentando en este mismo hilo.

En tu pregunta sobre si se debe capturar (utilizar try) o crear la excepción, veo algo que no
debes haber entendido correctamente. Las excepciones que no existen, deben crearse
(apartado 2), pero aún así en algún momento – cuando sucedan - deberán capturarse (con
try). Por tanto, la creación y la captura no
son excluyentes, sino complementarias. En el caso de las excepciones que ya están creadas
(apartado 1) simplemente debes capturarlas (con try) por que otro programador ya ha hecho
el trabajo de creación por ti.

Respecto a la ampliación de material, deberías tener tener suficiente con mis comentarios del
blog y el material adicional que os propuse en su día (en concreto, curso de Java, apartado
7.3. Creación de excepciones de usuario). Allí tienes un ejemplo completo comentado. Si con
esto no tienes suficiente, dime qué dudas concretas tienes.

De todas formas, espero haberte solucionado un buen puñado de dudas.

Un saludo,

Cristian.

Quincena 10. Orientaciones didácticas Página 7 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

De Santiago Tur Querol:


Hola Cristian,
Primero te quería comentar que cuando leí la linea del tablón donde indicas lo del material, como ponías
que hasta que no estuviera corregida la PEQ9 no empezáramos, no me quedé con los detalles. Y cuando
cogí la práctica, únicamente leí la entrada en la web, por lo tanto me quede con la mitad del material. A
parte de esto lo que quería comentarte es que entiendo que cuando se pone una excepción y, por
ejemplo no se cumple una condición y queremos mandar un mensaje a la clase de la excepción, hay que
poner la línea throws new NombreExcepcion("valor");, y así se supone que el "valor" se queda
almacenado en la variable de la excepción y si queremos nos lo puede devolver para sacarlo por pantalla.
O no es así? porque no me funciona.

Saludos,

Santi.

De Cristian Jorge Garcia Marcos:


Hola Santi,

No entiendo qué quieres decir en la frase "cuando se pone una excepción", las excepciones o se
lanzan (throws) o se capturan (try/catch/finally), no se "ponen". Intedtad utilizar correctamente el
vocabulario técnico, porque si no ya sabéis que la comunicación se complica, y lo que es peor (en
especial para vosotros) se ralentiza.

De todas formas, intentaré explicarte algo con lo que he entendido. Si se cumple la condición, no
tienes que mandar ningún mensaje a la clase de la excepción, sino que la clase de la excepción habrá
lanzado una excepción y tú deberás controlar la recogida (capturar) esa excepción en tu código. Lo de
sacar un valor o no sacarlo no es importante, lo importante es que captures la excepción y muestres
un mensaje propio, en lugar del que te envia el JVM.

La captura de las excepciones es "por si acaso". Es decir, la mayoría de veces, no se ejecutará el


bloque de código catch, por que no suelen producirse excepciones (por eso llevan ese nombre). Pero
lo que tú haces al capturar la excepcion es controlar que, en caso de que ocurra esa excepción, tú
serás quién controla qué va a pasar, por ejemplo, poniendo un mensaje del tipo "Error, ha pasado tal
cosa" y con ello consigues evitar que ocurra algo que no quieres que ocurra (en el caso de crear tus
propias excepciones) o bien evitar que la JVM envíe su propio mensaje (que son mensajes que dan
miedo).

Un saludo,

Cristian.

De Santiago Tur Querol:


Hola Cristian,

Efectivamente me refería a cuando se lanza. Cuando se lanza una excepción se acompaña de un


mensaje y yo lo que quería saber es si tengo que capturar el mensaje lanzado, pero ya me has
respondido. Entonces, para que sirve lanzar el mensaje?

Saludos,
Santi.

De Cristian Jorge Garcia Marcos:


Hola Santi:

Quincena 10. Orientaciones didácticas Página 8 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

No se captura ni se lanza el mensaje, sino la excepción: se lanza una excepción y se captura


una excepción. Tratar de una manera u otra esa excepción (por ejemplo con un mensaje) es
algo que debe controlar el programador.

Creo que hay algo que te está confundiendo, pero no consigo saber exactamente qué es. Como
sé que es complicado haceros venir a las tutorías, te remito a otro ejemplo más práctico si cabe
que el de la documentación adicional, para ver si con esto lo entiendes. Lo tienes en esta
dirección:

http://www.cica.es/formacion/JavaTut/Cap6/crear.html

Esta es la última bala que me queda como recurso de explicación de las excepciones. Espero
que te sirva.

Un saludo,

Cristian.

Quincena 10. Orientaciones didácticas Página 9 de 10


Desarrollo de Funciones en el Sistema Informático
Curso 2008/2009

De Cristian Jorge Garcia Marcos:


Una més que ningú ha comentat. Què ocorreix quan es fa la cerca d'un Equip que no existeix?

Ho heu de comprovar amb el vostre codi. En cas que l'execució del mètode siga fallida, haureu de llançar
i/o capturar l'excepció.

Salutacions,

Cristian.

NOTA: Todos los comentarios tienen la autorización expresa de publicación de sus respectivos autores. Aquellos comentarios que aparecen firmados bajo la
autoría Anónimo, también se han publicado autorizados con la condición de no mostrar el nombre del autor.

Esta obra está bajo una licencia Reconocimiento-Compartir bajo la misma licencia 3.0 España de Creative Commons. Para ver una copia de
esta licencia, visite http://creativecommons.org/licenses/by-sa/3.0/es/ o envie una carta a Creative Commons, 171 Second Street, Suite
300, San Francisco, California 94105, USA.

Quincena 10. Orientaciones didácticas Página 10 de 10

Anda mungkin juga menyukai