Ventajas y desventajas del polimorfismo en java

Explicar brevemente los siguientes conceptos (0.75 Ptos):

A) Clases de envoltura

A. Clases predefinidas que permiten el manejo de los tipos primitivos como objetos (tipos referencia). Por ejemplo

Character como objeto en lugar de char. Ejemplo:int i = 5; Integer i = new Integer(i);

B) Sobrecarga de operadores

a. Operadores que se pueden redefinir de tal forma que cumplen distinto papel en ese tipo, como por ejemplo el operador + para la concatenación de cadenas en Java y la suma de valores numéricos primitivos.

C) Congelar propiedades

a. Se garantiza a los clientes que una propiedad no cambia de implementación, incluida la redefinición ante la presencia de herencia de propiedades entre clases. En Java se consigue con el modificar final.

D) Regla de nombres en herencia múltiple

a. Dos propiedades diferentes concretas de una clase no pueden tener el mismo nombre final. Para evitar estos conflictos o se proporcionan mecanismos como renombrados (Eiffel) o bien se impide la herencia múltiple de clases (Java)

E) Invariante de clase

a. Es una aserción que expresa restricciones de consistencia generales que se aplican a cada instancia de la clase como un todo o una aserción que debe satisfacer cada instancia de C en todos los momentos estables (momentos en los que la instancia se encuentra en un estado observable).

Describir los principios de modularidad: acceso uniforme, abierto-cerrado y elección única. (0.75 Ptos)

Acceso uniforme

: todos los servicios ofrecidos deben estar disponibles a través de una notación uniforme sin depender de su implementación Ej: acceso a atributos de los objetos a través de métodos, usando una notación uniforme ocultando la implementación. De esta forma no se sabe si se acceden a datos almacenados o datos calculados.

Abierto-Cerrado

Abierto a extensión y cerrado para ser usado por otros módulos. Los módulos pueden ser extendidos mediante mecanismos de extensión como la herencia o genericidad, pero por otro lado no

son modificables (cerrados a modificación). Esto permite extender de una forma limpia sin tener que modificar código de la clase que se extiende.

Elección Única

Cuando se deben soportar un conjunto de alternativas, uno y sólo uno de los módulos debe conocer toda la lista de alternativas. Esto evita que cuando haya cambios afecten a más de un módulo, sabiendo localizar claramente el módulo responsable de esa toma de decisiones.

Estructura estática

Clase y tema 3- Estructura Dinámica: Objeto. El principio de abierto-cerrado y elección único se ve en el Tema-4. Herencia, incidiendo en la extensión y uso de polimorfismo y ligadura dinámica.

Aproximación casual :
No nos preocupamos, confiamos en que hay suficiente memoria y el programador y el entorno se desentienden de cualquier gestión para la liberación y recuperación de memoria.

· Reclamación Manual: liberación manual de los objetos. El programador es responsable de codificar las sentencias en el código que libere la memoria reservada mediante instrucciones especiales (Ej: dispose, free, etc.). El problema que genera, es la posibilidad de cometer errores y liberar objetos a los que luego se accede.

· Gestión Automática de Memoria: sistema automático de recogida de objetos no alcanzables, el propio entorno de ejecución detecta que objetos son inalcanzables y libera el espacio en memoria, evitando errores por parte del programador. Existen dos variantes de mecanismos de gestión automática de memoria: contar referencias, que conlleva una perdida de rendimiento (computación y espacio) que además no funciona bien con ciclos, y por otro lado, garbage collection, mecanismo proporcionado por el entorno de ejecución que realiza una fase de detección (marcado) y reclamación (barrido). Se ejecuta bajo demanda (memoria < cota)="" con="" una="" penalización="" en="" rendimiento="" del="" 5%="" al="" 15%.="" como="" solución="" se="" plantea="" el="" uso="" de="" un="" hilo/thread="" separado="" y="" la="" inclusión="" de="" nuevos="" algoritmos="" como="" el="" escarvado="" de="" generaciones="" (generation="" scavenging)="" o="" algoritmos="" paralelos.="" en="" la="" actualidad="" siguen="" aportándose="" nuevos="">

La clasificación se divide en dos grupos fundamentales:

Universal: que incluye a su vez el polimorfismo de inclusión y paramétrico

o Inclusión : cuando existen relaciones de conformidad (a través de la herencia) se permite

Que una referencia de un tipo apunte a objetos de su subtipo

_ Ej: polígono = rectángulo; // donde el tipo de rectángulo hereda del de polígono

o Paramétrico polimorfismo en genericidad (Tema 5. Genericidad): cuando se utiliza un

Tipo como plantilla o contenedor de otros tipos

_ Ej: Pila pilaEnteros; Pila pilaClientes;

Ad-Hoc

o Sobrecarga de métodos: métodos con mismo nombre pero distinta signatura (orden,

Número y tipo de argumentos)

_ Ej: Java, constructores de String

o Sobrecarga de operadores: operadores que cumplen distinto papel en ese tipo

_ Ej: Java, operador + en cadenas

_ Ej: Eiffel, uso de infix y prefix

La programación parte de la idea de que es positivo hacer muchas comprobaciones sobre los valores que se nos pasan como argumentos actuales, aunque sean redundantes porque dichas comprobaciones se han realizado en otra parte del código. El diseño por contrato, parte de la afirmación contraria y es que añadir comprobaciones, añade más puntos para que el código contenga errores por lo que se debe minimizar el número de comprobaciones. Para ello propone la metáfora del contrato donde se reparten responsabilidades: el cliente debe comprobar precondiciones y el  proveedor debe comprobar postcondiciones

Programación defensiva:public float obtenerRaízCuadrada(float

F) {if (f < 0)="">throw new

RuntimeException();

// cuerpo del método y retorno del valor calculado

}

Diseño por contrato:public float obtenerRaízCuadrada(float

F) {assert

f > 0 : "El valor debe ser positivo."; // comprobar el cliente

// cuerpo del método y retorno del valor calculadoassert

resultado * resultado = f + cotaError; // postcondición proveedor

}

Explicar el principio de precondición razonable con un ejemplo. (0.5 Ptos)

Principio de la precondición razonable:

• La precondición de toda rutina (en un enfoque de diseño “exigente”) debe satisfacer los siguientes requisitos:

• La precondición aparece en la documentación oficial distribuida a los autores de módulos clientes. Es posible justificar la necesidad de una precondición exclusivamente en términos de la especificación. Por ejemplo, en el caso de implementar una pila acotada, donde el número de elementos que se pueden guardar está limitado:

Public class PilaAcotada {

Private boolean estáLlena() { … }

Public void añadir(E elemento) {

// no se puede añadir un elemento en una pila acotada

// si está llena (extraído de la documentación/especificación

Assert !EstáLlena();

// hacer operación

// añadir asertos como postcondiciones

}

}