Categories
Práctica 2011-2012

Práctica de Google Earth (2)

Un compañero pregunta lo siguiente:

En los ejemplos que hay en la practica siempre se muestra un solo kml. Pero si en el fichero de entrada pides mostrar mas de un kml, ¿compartirían la cabecera?
¿Y si fueran una Imagen o una posición con un tour? Ya que la cabecera del tour es distinta.

Respuesta:

Cada recurso se muestra con su propia cabecera, como si fuera un fichero KML independiente.

 

Categories
Práctica 2011-2012

Práctica de Google Earth

Espero que lo estéis pasando bien implementando vuestra práctica. Ahí va una aclaración:

Pregunta:

Si cuando leemos una línea que representa un Tour que contiene más de un FlyTo, el primero de ellos provoca un error (lanzando una excepción) ¿Debemos dejar de leer la línea o simplemente saltamos ese FlyTo? Es decir, manejamos la excepción en la lectura de la línea por parte del Tour, o delegamos esa responsabilidad a Aplicación?

Respuesta:

Cualquier excepción producida por un error en la creación de un recurso (posicion, imagen o tour), lo captura Aplicacion::crearRecurso(), como indica el enunciado en la sección 3.1.

En general, cualquier error en los valores de entrada produce una excepción y no seguimos leyendo ese recurso (o acción).

Categories
General

Curso 2011-2012. Asignaturas a extinguir

El curso pasado fue el último con docencia para la asignatura ‘Programación orientada a objetos’ de los planes de Ingeniería Informática (9190),  Ingeniería Técnica en Informática de Gestión (9288) e Ingeniería Técnica en Informática de Sistemas (9363).

Con el objetivo de disponer de un espacio adicional al Campus Virtual de la UA, aunque sea virtual, donde poder dar información sobre la asignatura de forma rápida y para todos, retomamos este blog, que había quedado en stand-by por diversas razones.

 

Categories
General

Atributos de clase constantes en C++

La inicialización de atributos estáticos constantes en C++ depende del tipo de constante que queramos crear.

Veamos que ocurre con el siguiente ejemplo (en comentario aparecen los números de línea para posterior referencia):

class Ejemplo {
  public:
   static const int x=10; // 10
   static const float PI =3.141592; // 11
   static const string s1="HOLA"; // 12
   static const string s2=string("HOLA"); // 13
   static const Ejemplo ejemplo1; // 14
   static const Ejemplo ejemplo2=Ejemplo(2); // 15
   Ejemplo(int x=0) : val(x) {}
private:
   int val;
};

Al intentar compilar esta declaración de clase con gcc (versión 4.3.3), aparecen estos errores:

atrib_constante.h:12: error: inicialización en la clase inválida para el miembro de datos static de tipo ‘const std::string’ que no es integral
atrib_constante.h:13: error: a call to a constructor no puede aparece en una expresión constante
atrib_constante.h:13: error: inicialización en la clase inválida para el miembro de datos static de tipo ‘const std::string’ que no es integral

que viene a decir que no se pueden inicializar constantes que no sean de tipo primitivo de C++ en la declaración de la clase. En la línea 15 el error de compilación es diferente:

atrib_constante.h:15: error: invalid use of incomplete type ‘class Ejemplo’
atrib_constante.h:8: error: forward declaration of ‘class Ejemplo’
atrib_constante.h:15: error: inicialización en la clase inválida para el miembro de datos static de tipo ‘const Ejemplo’ que no es integral

es decir, no podemos intentar crear en ese momento un objeto de clase Ejemplo, ya que ésta aún no está completamente definida. Sin embargo, sí podemos declarar objetos de clase (estáticos) de tipo Ejemplo dentro de la propia clase (línea 14), siempre y cuando no intentemos inicializarlos (construirlos) ahí. La solución a estos errores es simplemente realizar la inicialización en el fichero de implementación (o a continuación de la declaración de la clase):

class Ejemplo {
public:
 static const int x=10;
 static const float PI =3.141592;
 static const string s1;
 static const string s2;
 static const Ejemplo ejemplo1;
 static const Ejemplo ejemplo2;
 Ejemplo(int x=0) : val(x) {}
private:
 int val;
};

const string Ejemplo::s1 = "HOLA";
const string Ejemplo::s2 = string("HOLA");
const Ejemplo Ejemplo::ejemplo1;
const Ejemplo Ejemplo::ejemplo2 = Ejemplo(2);

En estas inicializaciones hay que tener en cuenta dos cosas:

  1. Hay que indicar el ámbito de las constantes, en este caso, la clase Ejemplo.
  2. No hay que poner el modificador ‘static’.

Fijémonos en ‘ejemplo1’. La inicialización no especifica a qué valor debe inicializarse el objeto. ¿Es por tanto necesaria? Si no lo hacemos obtendremos este bonito mensaje al intentar compilar y enlazar nuestro código para crear un programa ejecutable:

atrib_constante.cc:(.text+0x152): undefined reference to `Ejemplo::ejemplo1'

Es decir, ‘ejemplo1’ ha sido declarado pero no definido. Es necesario definirlo (construirlo) expresamente, mediante la instrucción de definición

const Ejemplo Ejemplo::ejemplo1;

Esto no es una declaración de ‘ejemplo1’ (ésta se hizo en la clase), sino su definición o, en otras palabras, su construcción. De hecho esa definición es equivalente a

const Ejemplo Ejemplo::ejemplo1=Ejemplo();

donde se ve explícitamente que al definir ‘ejemplo1’ estamos invocando al constructor por defecto de su clase.

Categories
General

¿Clases u objetos?

Una de las tareas de un analista de requerimientos es identificar las entidades que han de participar en la solución de un problema y decidir cuales de ellas son clases de objetos y cuales son simplemente instancias (objetos) de alguna clase. A modo de ejemplo, ahí van unos cuantos sustantivos que podrían aparecer en una fase temprana del análisis de un problema. Se trata de decidir si nombran clases u objetos. En el caso de ser una clase, pongo entre paréntesis una posible instancia de ella, y en el caso de ser objeto, una posible clase a la que puede pertenecer.

Entidad Clase Objeto
Leche Pascuala (Industria) OBJETO
Airbus 360 (Avión) OBJETO
Juan Albeniz (Persona) OBJETO
Juego de mesa CLASE (Parchís)
Asignatura POO 9999 (Asignatura) OBJETO
La final del abierto de EEUU
de tenis del año 2009
(Partido de tenis) OBJETO
Fabricante de automóviles CLASE (Seat)
Estudiante de informática CLASE (Juan Albeniz)
El coche con nº de serie
UGA12345678
(Coche) OBJETO
Juego CLASE (Póker)
Ajedrez (Juego de mesa) OBJETO
Avion CLASE (Airbus 360)
Agua Mineral CLASE (Agua de Fuente Limpia)

En general, algo será una clase si puede tener instancias. Será un objeto si es algo único que comparte características con otras cosas similares. Sin embargo, lo que a primera vista podría parecer una clase podría ser en realidad un objeto, y viceversa.

¿Te parecen correctas las decisiones tomadas sobre los ejemplos dados arriba? Si no estás de acuerdo con alguna de las propuestas, deja tu comentario proponiendo alguna alternativa.

Categories
General

Pensando en objetos

00-8bit
(CC) pablosanz @ flickr

Allá por 1977, Alan Kay, creador del lenguaje orientado a objetos Smalltalk dijo

Es más fácil enseñar Smalltalk a niños que a programadores profesionales.

Lo cual puede parecer sorprendente a primera vista. Sin embargo, si pensamos que uno razona en el paradigma orientado a objetos (OO) en términos de objetos del mundo real y no de datos en memoria, que estos objetos (el coche de mi vecino, el balón de Manu, el sillón de papá…) se clasifican en clases de objetos (Coche, Balón, Mueble,…) y que estás clases, a su vez, se organizan en jerarquías como la del reino animal o vegetal, quizás entendamos porqué a un programador ‘tradicional’ le cuesta más cambiar de paradigma de programación que a un niño ‘sin prejuicios’. Si a esta forma de ‘ver el mundo’ le añadimos la visión de un programa no como secuencia de instrucciones, sino como una colección de objetos con vida propia que se envian mensajes entre sí para llevar a cabo ciertas tareas, como si de laboriosos enanitos se tratara, los niños ganan por goleada.

Aclaremos que aquí entendemos por programador tradicional a aquel que está habituado a trabajar con lenguajes imperativos, como C, Pascal o incluso C++ cuando no usas técnicas OO. El cambio de paradigma cuesta. Cuando la parte más importante de una aplicación es la comunicación entre sus diferentes componentes (objetos) y no tanto la algoritmia que resuelve las pequeñas tareas que, combinadas, darán lugar al resultado final deseado, resulta obvio ver que nos movemos en un terreno diferente al ‘tradicional’.

¿Y porqué tenemos que cambiar de paradigma de programación? Se supone que con un lenguaje imperativo podemos resolver cualquier problema que sea computable… Sí, podemos hacerlo, pero pagando un alto precio: la complejidad de la solución se volverá inmanejable. Es lo que ocurrió en el mundo del desarrollo de software hace un par de décadas: la llamada crisis del software, la cual, según algunos, es crónica (he aquí algunos ejemplos recientes).

¿Es el paradigma orientado a objetos la panacea para evitar los problemas que originaron la crisis del software? No, no lo es, pero ayuda en gran medida a aliviar los problemas relacionados con la estructura y mantenibilidad del software. Además de una metodología como esta, que no deja de ser una herramienta, hacen falta desarrolladores que sepan utilizarla correctamente.

Categories
General

Comienzo de clases. Curso 2009-2010

Como todos sin duda sabéis, las clases comienzan el próximo Lunes 14 de Septiembre. Esta primera semana presentaremos la asignatura, normas de evaluación, asistencia, etc… Ya está abierto el plazo de matriculación a prácticas (servicios Web de la EPS), hasta el próximo día 17. El sorteo de turnos de prácticas se realizará el día 18 y las clases de prácticas empezarán la semana siguiente (el día 21).

Categories
General

Programación orientada a objetos. Curso 2009-2010

Bienvenido al blog de POO.

Este blog está asociado a la asignatura Programación orientada a objetos (POO) de las titulaciones de Ingeniería Informática de la Universidad de Alicante, impartidas en la Escuela Politécnica Superior (EPS). Dirigido principalmente (aunque no únicamente)  a los alumnos de  POO, en el intentaremos dar información adicional a la que podreís encontrar en el Campus Virtual, así como noticias relacionadas con la POO y los lenguajes y herramientas orientados a objetos. También esperamos que sirva como vehículo para comentar vuestras inquietudes sobre los asuntos que en él se traten.