Etiqueta: UA
Esta vez he tenido suerte, tras haber estado estudiando Programación Orientada a Objetos y sufriendo con sus prácticas interminables herencias, polimorfismos y enlaces dinámicos puedo decir que he aprobado. El exámen de esta asignatura consta de 20 preguntas tipo test que puntuan sobre 4, más una parte práctica de 4 preguntas donde hay que explicar términos mediante teoría y ejemplificaciones sobre 6.
La verdad es que con un 4 ya hacía media y podía aprobar, pero más vale el bonito 6,9 que he sacado de nota final. Ahora falta esperar a la media, que rondará el 7,7. Así que nada, se que esto no le importa a demasiada gente pero soy feliz, me he quitado una de las asignaturas más difíciles de segundo a la primera 
2 Febrero, 2010
La Programación Orientada a Objetos surge en 1967 de la mano del Norwegian Computer Center y su “Simula”. Para hablar de un lenguaje de programación orientado a objetos hemos de hacer referencia a la abstracción, es decir, a la omisión de detalles o aspectos de una estructura o artefacto con el fin de resaltar más claramente otros detalles. Es la abstracción lo que define un lenguaje orientado a objetos. De este modo, en estos podemos encontrar distintos mecanismos como la ocultación de información y el encapsulamiento (separación estricta entre interfaz o qué hace e implementación o cómo se hace).
Mediante los mecanismos de abstracción llegamos al paradigma orientado a objetos. Un paradigma es una serie de normas mediante las cuales se representa o entiende la realidad, en este caso aplicados a la programación. El Paradigma Orientado a Objetos es la metodología de desarrollo de aplicaciones organizadas como colecciones cooperativas de objetos, los cuales instancian clases, que a su vez se ordenan en jerarquías de clases que se relacionan mediante herencia.
Durante las últimas dos décadas la POO ha adquirido una gran popularidad debido a diversos factores tales como su fácil escalabilidad y su sencilla comprensión utilizando los mecanismos de abstracción simulando problemas de la vida real y razonando con metáforas. Por otra parte se han desarrollado grandes y potentes herramientas OO, tales como librerías, IDEs, etc.
Pero, además de todo lo mencionado, hay algo más importante que se debe saber sobre la POO, y es su “mundo”. Con la OO se presenta ante el programador, acostumbrado al paradigma imperativo o lógico, un nuevo mundo que se estructura en:
Agentes y comunidades: un programa OO se estructura como una comunidad de agentes que interactúan (objetos), de este modo cada uno de ellos tiene un rol en la comunidad y es utilizado por otros miembros de la misma.
Mensajes y métodos: cada objetos recibe mensajes sobre lo que debe hacer para posteriormente elegir el método mediante el cual hacerlo. Cada mensaje puede ser interpretado de distinto modo dependiendo del receptor.
Responsabilidades: son el comportamiento de los objetos. En la POO no preguntamos lo qué podemos hacer a las estructuras de datos, si no que preguntamos qué pueden hacer ellas por nosotros.
Objetos y clases: en la OO todo es un objeto. Un objeto es una encapsulación de un estado (valores de los datos) y comportamientos (operaciones) que instancian clases y están configurados a partir de otros objetos. Los objetos se agrupan en categorías llamadas clases.
Jerarquía de clases: la jerarquía de clases se establece en la herencia. Ésta utiliza la llamada generalización, es decir, en la vida real las características de un ente superior son aplicables a uno inferior, de este modo las características de figura geométrica son aplicables a rectángulo, a círculo, a triángulo, etc. Eso es herencia.
Enlace de métodos: existen dos tipos de enlace, el estático, que se realiza durante la compilación del programa, y el dinámico, que se realiza durante su ejecución.
En resumen, según Alan Kay, toda POO debe tener las siguientes características:
- Todo es un objeto.
- Cada objeto tiene su propia memoria configurada a partir de otros objetos.
- Los objetos instancian clases.
- Todos los objetos de una misma clase pueden recibir los mismos mensajes. Las clases son el lugar donde se almacena el comportamiento y la estructura interna de los objetos.
- Las clases se organizan en una jerarquía de herencia.
- Un programa es un conjunto de objetos que se relacionan entre sí mediante el envío de mensajes.
30 Diciembre, 2009
Soy estudiante y, sí, soy vago. Pero aunque no lo fuera, si una persona tiene apenas una semana para realizar tres prácticas (dos de ellas de programación) y otros dos exámenes, además de otro tipo de compromisos personales, sin ningún tipo de agobio o malestar, esa persona se convertirá automáticamente en un nuevo dios al que adorar. Y así estoy, amigos, con el agua hasta el cuello y con un mes por delante que se presenta más negro que el carbón; todo ello aliñado con un futuro nada halagüeño que habla de un plan llamado “de Bolonia” en el que se limpiarán las partes nobles con mi plan de estudios actual y del cual se poco más que nada. Lo peor de todo es que esa desinformación es generalizada, al menos en Alicante.
Después del párrafo de queja, protesta y lloriqueo variado, he aquí mi planning de la primera mitad de noviembre, mi mes favorito a partir de ahora.
Además de un bonito examen de REDES para este viernes, que como no me ponga mañana con él, tendré un bonito rosco. Cuantas ganas tengo de tener unas vacaciones lejos de tanto trabajo, tanto del obligado como del voluntario, así no hay quien viva.
29 Octubre, 2009
Con todo esto de la orientación a objetos se van aprendiendo cosas nuevas y dejando atrás el paradigma “imperativo” al que tan acostumbrado estaba. La verdad es que de momento me resulta algo extraño este tipo de programación, demasiadas dependencias de un lugar y de otro, pero realmente es bastante efectivo y cómodo, eso una vez definidas las clases necesarias, porque antes es un verdadero jaleo.
Bueno, hablo de clases pero no digo lo que es, voy mejorando. Las clases son, y cito, una “abstracción de los atributos (características), operaciones, relaciones y
semántica comunes a un conjunto de objetos“, vamos, que nos hemos quedado igual. Se trata de una definición de un tipo propio, es decir, un contenedor de variables y de funciones propias solo utilizables una vez introducida la clase en el programa. Para comprenderlo debemos hacer caso a la siguiente teoría: “No hay noción de programa principal, y los subprogramas no existen como unidades modulares independientes, sino que forman siempre parte de alguna clase.” Y así, nos cargamos casi en su totalidad el paradigma imperativo.
Una clase está compuesta por un nombre o identificador, atributos o variables, roles de relación con otras clases y operaciones propias. Y como lo mejor para comprender lo que es una clase es un ejemplo, a continuación os expongo uno:
class TClase
{
public: // Interfaz y operaciones públicas que se le permite manejar al usuario.
setY(float);
setX(float);
getY();
getX();
private: // Formada normalmente por atributos o variables, no pueden ser modificadas directamente por el usuario.
int x, y;
};Una vez definida la clase, podremos crearla dentro de nuestro programa definiendo TClase p; por ejemplo, y de este modo acceder a las funciones de public que deberemos de haber definido en el archivo .cc correspondiente y con las que manejaremos los atributos de private.
Y de momento poco más. Según vayamos avanzando las clases de Programación Orientada a Objetos y Programación y Estructura de Datos iré comentando más cosas interesantes y corrigiendo fallos que vaya encontrando.
6 Octubre, 2009
