P3

La forma canoníca en C++ incluye el constructor copia, el destructor, el operador asignación, el constructor por defecto y cualquier otro constructor parametrizado. F. V.

En JAVA la forma canoníca incluye constructor, equals, hashCode, toString y clone. F. V.

Tato la herencia protegida como la privada permiten a una clase derivada acceder a las propiedades privadas de la clase base. F. V.

Independientemente del tipo de herencia la clase base siempre podrá acceder a lo público, protegido y default heredado pero no a lo privado. F. V.

En JAVA la clase deberá contener al menos un método abstracto para ser declarada como tal en C++ no. F. V.

La siguiente sentencia class S {public final void f(){}} constituye una interfaz en JAVA. F. V.

La siguiente sentencia interfaz S {void f();} constituye una interfaz en C++. F. V.

Una clase abstracta se caracteriza por declarar todos sus métodos de instancia como abstractos. F. V.

Desde un método de una clase derivada nunca puede invocar un método implementado con idéntica signatura de su clase. F. V.

Desde un método de una clase derivada nunca puede invocarse un método implementado en esta con el mismo nombre que en la clase base. F. V.

En Java los métodos de instancia con polimorfismo puro pero no abstracto tienen enlace dinámico. F. V.

Una operación de clase solo puede acceder directamente a atributos de clase. F. V.

Una operación de instancia puede acceder directamente a atributos de clase y de instancia. F. V.

Una operación de clase no es una función miembro de la clase. F. V.

En la misma clase podemos definir constructores de con distinta visibilidad. F. V.

El modificador static es correcto para JAVA pero no para C++ cuando lo usamos con constructores. F. V.

Un buen diseño OO se caracteriza por un alto acoplamiento y una baja cohesión. F. V.

Mediante la herencia de implementación heredamos la implementación de los métodos de la clase base pero no la interfaz de esta. F. V.

La genericidad es un tipo de polimorfismo. F. V.

En JAVA y en C++ todas las clases son polimórficas. F. V.

El downcasting en JAVA y en C++ es siempre dinámico. F. V.

Si la conversión, downcasting, es fuera de la jerarquía de herencia JAVA dará error de ejecución. F. V.

El downcasting implica deshacer el principio de sustitución. F. V.

En JAVA si no se captura una excepción lanzada por un método da error la compilación. F. V.

La instrucción throw en JAVA solo permite lanzar objetos que son de la clase throwable o clases derivada de esta. F. V.

Uno de los objetivos del tratamiento de errores mediante excepciones es el manejo de errores del resto del código. F. V.

Si no se captura una excepción por un método, el programa no advierte que ha ocurrido error y continúa su ejecución que llamo a este. F. V.

El polimorfismo es un tipo de genericidad. F. V.

En JAVA. Siempre es obligatorio especificar que excepciones verificadas (checked exceptions) lanza un método mediante una clausula throws tras la lista de argumentos. F. V.

Si se produce una excepción el método que la provoca se cancela y se continúa la ejecución en el método que llamo a este. F. V.

Si se produce una excepción en un constructor el objeto se construirá con los valores por defecto. F. V.

Todas las excepciones son checked exception salvo las runtime que son uncheked exception. F. V.

La cláusula throws de un método incluirá todas las excepciones uncheked exception que puedan producirse en este y no estén dentro del bloque try catch que les capture. F. V.

El orden de las excepciones en los bloques catch no es relevante. F. V.

Podemos poner un bloque finally sin poner bloques catch. F. V.

El bloque finally solo se ejecutará si se produce alguna excepción en el bloque try al que este asociado. F. V.

IllegalArgumentException, ArrayIndexOutOfBoundsException, ClassCastException y IOExceptio son excepciones del tipo runtimeException y por tanto no es necesario capturarlas ni indicar throws en el método en el que se provoquen. F. V.

La genericidad se considera una característica opcional de los lenguajes. F. V.

La genericidad se considera una característica opcional de los lenguajes OO. F. V.

No se puede derivar una clase genérica de una clase no genérica. F. V.

En JAVA no podemos crear interfaces genéricas. F. V.

En los métodos genéricos solo podremos usar los métodos definidos en Object. F. V.

En la genericidad restringida solo podremos usar los métodos de Object al implementar los métodos. F. V.

La API de reflexión de JAVA incluye métodos para obtener la signatura de todos los métodos. F. V.

La reflexión permite que un programa obtenga información sobre sí mismo en tiempo de ejecución. F. V.

Para usar reflexión en JAVA hemos de conocer el nombre de las clases den tiempo de compilación. F. V.

En JAVA el concepto de meta-clase se presenta con la clase Class. F. V.

Con el uso de la reflexión solo podemos invocar métodos de instancia. F. V.

La reflexión solo es útil para trabajar con componentes JavaBeans. F. V.

La reflexión es demasiado compleja para usarla en aplicaciones de propósito general. F. V.

La reflexión reduce el rendimiento de las aplicaciones. F. V.

La reflexión no puede usarse en aplicaciones certificadas con estándar 100% Pure Java. F. V.

Mediante reflexión podemos saber cuáles son las clases derivadas de una clase dada. F. V.

Mediante reflexión no podemos saber cuál es el método que se está ejecutando en un determinado momento. F. V.

Podemos usar reflexión para encontrar un método heredado (solo hacia arriba) y reducir código condicional. F. V.

La refactorización debe hacerse siempre apoyándonos en un conjunto de tests completo y robusto. F. V.

Una clase con gran número de métodos y atributos es candidata a ser refactorizada. F. V.

Los métodos grandes (con muchas instrucciones) son estructuras que sugieren la posibilidad de una refactorización. F. V.

En la refactorización se permite que cambie la estructura interna de un sistema software aunque varié su comportamiento externo. F. V.

Un ejemplo de refactorización seria mover un método arriba o abajo en la jerarquía de herencia. F. V.

Los frameworks no contienen implementación alguna, únicamente un conjunto de interfaces que deber ser implementados por el usuario del framework. F. V.

Un framework invoca mediante enlace dinámico a nuestra implementación de interfaces propios de framework. F. V.

Hibernate es un framework para congelar en memoria el estado de nuestra aplicación. F. V.

JDBC es un framework de JAVA que usan los fabricantes de sistemas de gestión de bases de datos para ofrecer un acceso estandarizado a las bases de datos. F. V.

El usuario de un framework implementa al componente declarado de los interfaces de framework mediante herencia de implementación. F. V.

El usuario de un framework implementa el comportamiento declarado en los interfaces del framework mediante herencia de interfaz. F. V.

Un framework es un conjunto de clases cuyos métodos invocamos para que realicen unas tareas a modo de caja negra. F. V.

En JAVA el acceso a bases de datos se hace con librerías propietarias de SGBD cuyos interfaces no tienen ningún estándar. F. V.

Para poder utilizar un framework, es necesario crear clases que implementen todas las interfaces declaradas en el framework. F. V.

Una librería de clases proporciona una funcionalidad completa, es decir, no requiere que el usuario implemente o herede nada. F. V.

El polimorfismo es una forma de reflexión. F. V.

En el proceso de diseño de un sistema de software se debería intentar aumentar el acoplamiento y la cohesión. F. V.

Cuando diseñamos sistema OO las interfaces de las clases que diseñamos deberían estar abiertas a la extensión y cerradas a la modificación. F. V.

Todo espacio de nombre define su propio ámbito, distinto de cualquier otro. F. V.

Una colaboración describe como un grupo de objetos trabaja conjuntamente para realizar una tarea. F. V.

En el diseño mediante tarjetas CRC utilizamos una tarjeta para cada clase. F. V.

Una tarjeta CRC contiene el nombre de una clase, su lista de responsabilidades y su lista de colaboradores. F. V.

La robustez de un sistema software es un parámetro de calidad intrínseco. F. V.

El principio abierto-cerrado indica que un componente software debe estar abierto a su extensión y cerrado a su modificación. F. V.

Con el diseño OO es perfectamente posible y deseable hacer uso de variables globales. F. V.

En el diseño por contrato son dos componentes fundamentes las pre y pos condiciones. F. V.

Los métodos definidos en una clase derivada nunca pueden acceder a las propiedades privadas de una clase base. F. V.

Una clase abstracta se caracteriza por no tener definido ningún constructor. F. V.

La siguiente clase: class S {public: S(); S(const S &s); virtual ~S();}; constituye una interfaz en C++. F. V.

Desde un método de una clase derivada nunca puede invocarse a un método implementado con la idéntica signatura de una de sus clases base. F. V.

Los métodos virtuales son métodos abstractos. F. V.

Los métodos abstractos son métodos con enlace dinámico. F. V.

Los constructores de las clases abstractas son métodos con enlace dinámico. F. V.

Un atributo de clase debe tener visibilidad pública para poder ser accedido por los objetos de la clase. F. V.

Un método sobrecargado es aquel que recibe como argumento al menos una variable polimórfica. F. V.

Un método tiene polimorfismo puro cuando devuelve una variable polimórfica. F. V.

Un método tiene polimorfismo puro cuando devuelve una variable polimórfica. F. V.

En C++, si no se define un constructor sin argumentos explícitamente, el compilador proporciona uno por defecto. F. V.