UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD
PROGRAMACION ORIENTA A OBJETOS
ING. CESAR ORLANDO JIMENEZ ANGARITA
2010
PROGRAMACIÒN ORIENTADA A OBJETOS
CESAR ORLANDO JIMENEZ ANGARITA
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD
ESCUELA CIENCIAS BASICAS, TECNOLOGIA E INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
2010
CONTENIDO
Lección 1
CAPÍTULO 1. CONCEPTOS BASICOS ORIENTADOS A OBJETOS
1.1. (TOMADO DEL LIBRO PROGRAMACIÓN DE COMPUTADORES DE JOSÉ CÁRCAMO SEPÚLVEDA, EDICIONES UIS).
1.2. ¿Que es un objeto? ... 1
Lección 2 1.3. Cada objeto tiene un conjunto de características o atributos que lo hacen diferente a los demás. ... 2
1.4. Inicialmente podríamos decir que un objeto es algo que tiene atributos y comportamientos propios. ... 2
Lección 3 1.5. ¿Podríamos hacer la representación de un objeto del mundo real? ... 3
1.6. Tipo abstracto de datos ... 3
Lección 4 1.7. Características de datos: Por ejemplo hora, minutos y segundos... 4
1.8. Para representar el objeto anterior debemos considerar tres aspectos ... 5
Lección 5 1.9. ¿ Que es un mensaje? ... 5
1.10. Beneficios de la POO (tomado de monografías.com) ... 6
1.11. Problemas derivados de la utilización de OOP en la actualidad (tomado de monografías.com) ... 6
1.11.1. Curvas de aprendizaje largas. ... 6
1.11.2. Dependencia del lenguaje ... 7
1.11.3. Determinación de las clases ... 7
1.11.4. Performance. ... 7
CAPITULO 2. INTRODUCCIÓN Y ELEMENTOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A OBJETOS (POO) Lección 6 2.1 Introducción ... 8 2.2 ¿Porqué POO? ... 9 2.3 ¿Que es la POO? ... 10 Lección 7 2.4 Ventajas de POO ... 11 Lección 8 2.5. Desventajas de la tecnología orientada a objetos ... 12
Lección 9 2.6 Evolución de la programación ... 13 2.6.1. Programación lineal. ... 13 2.6.2. Programación Modular ... 13 2.6.3. Programación Estructurada ... 14 Lección 10 2.7. Comparación entre la Programación orientada a Objetos y la programación estructurada. ... 14
2.7.1. Paradigma Estructurado ... 14
2.7.2 Paradigma Orientado a Objetos ... 16
2.7.2.1.Ventajas del Modelo orientado a objetos con respecto al modelo estructurado ... 17
CAPITULO 3. PROPIEDADES BÁSICAS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS Lección 11 3.1 Abstracción ... 19 Lección 12 3.2 Encapulación ... 20 Lección 13 3.3 Moduaridad ... 22 Lección 14 3.4 Jerarquia ... 23 Lección 15 3.5 Polimrfismo ... 24 3.6 Herencia ... 25 3.6.1 Tipos de herencia ... 26 3.7 ACTIVIDADES COMPLEMENTARIAS ... 26
UNIDAD 2. ESTRUCTURA DE UN OBJETO - INTRODUCCION A JAVA CAPITULO 4. ANALISIS DE LA ESTRUCTURA Y COMPORTAMIENTO DE UN OBJETO Lección 16 4.1 Análisis de la Estructura de Objetos. ... 28
4.1.1 Objetos y Tipos de Objetos ... 28
Lección 17 4.1.2 Asociaciones de Objetos... 28
Lección 18 4.1.3 Jerarquías de Generalización ... 28
4.1.4 Jerarquías Compuestas. ... 29
4.1.5 Diagramas de relación entre los objetos ... 29
4.1.6 Esquemas de Objetos. ... 30
4.2 Análisis del comportamiento de objetos ... 30
4.2.1 Estados de un Objeto. ... 30
4.2.2 Eventos ... 31
4.2.3 Tipos de Eventos. ... 31
4.2.4 El Ciclo Vital de un Objeto Objeto. ... 33
4.2.5 Interacciones entre tipos de objetos Objeto. ... 33
4.2.6 Operaciones Objeto. ... 34
4.2.7 Fuentes externas de eventos Objeto. ... 35
4.2.8 Reglas deactivación Objeto. ... 35
4.2.9 Condiciones de Control Objeto. ... 35
4.2.10 Subtipos y Supertipos de Eventos Objeto. ... 36
4.3 Diseño de la Estructura y Comportamiento de un Objeto Objeto. ... 37
4.3.1 Objeto Objeto. ... 37
4.3.2. Estructura de un Objeto. ... 38
4.3.2.1.Componentes Objeto. ... 39
Lección 19 4.3.3 Diferencia entre operación y método Objeto. ... 40
4.3.5 Herencia Múltiple. Objeto. ... 41
Lección 20 4.3.6 Selección del Método Objeto. ... 41
4.3.7 Polimorfismo Objeto. ... 42
4.3.8 Notación. Objeto. ... 42
4.4 ACTIVIDADES COMPLEMENTARIAS Objeto. ... 44
CAPITULO 5. FUNDAMENTOS DE JAVA Lección 21 5.1 Introducción ... 46
5.2 Características de Java ... 47
5.2.1 Diferencias Con C++ ... 50
5.3 Estructura de un programa en Java ... 51
5.3.1 Creación de un primer programa ... 53
5.3.1.1 Métodos de definición ... 53
5.3.1.2 Palabras clave ... 54
Lección 22 5.3.2 Tipos de datos y declaraciones ... 55
5.3.2.1 Tipos de datos simples ... 55
5.3.3 Operadores y expresiones ... 59
Lección 23 5.3.4 E/S caracteres: ... 62
Lección 24 5.3.5 Estructuras De Control ... 64
5.3.5.1 Las sentencias condicionales: if y switch ... 65
5.3.5.1.1 La sentencia if – else ... 65
5.3.5.1.2. La sentencia switch ... 66
5.3.5.2. Sentencias de iteración o bucles: for, do, while ... 68
5.3.5.2.1 Bucle while ... 68
5.3.5.2.2 Bucle do-while ... 69
5.3.5.2.3 Bucle for ... 69
Lección 25 5.3.5.3 Sentencias de salto: break, continue y return ... 71
5.3.5.3.1 Sentencia break ... 71
5.3.5.3.2 Sentencia continue ... 72
5.3.5.3.3 Sentencia return ... 73
5.4 ACTIVIDADES COMPLEMENTARIAS ... 74
CAPITULO 6. GUIA DE LABORATORIO Lección 26 6.1. Caja de dialogo... 76
6.2. Programacion de arregos... 78
6.3. Lectura de un vector por teclado ... 79
6.4. Asignacion de un vector con numeros Aleatorios ... 79
6.5. Ordenamiento de un Vector Método Lineal ... 80
6.6. Ordenamiento de un Vector Método Burbuja ... 80
6.7. Busqueda de un elemento en un vector ordenado. Método Secuencial ... 81
6.8. Busqueda de un elemento en un vector ordenado. Metodo Binaria ... 82
6.9.1. Prog 1. Creación de una clase Arreglo ... 83
6.9.2. Prog2. Uso de un Objeto StringBuffer para la presentación de un vector ... 86
6.9.3. Programa 3. Invertir un Arreglo ... 88
Lección 27 6.10. Proramacion avanzada. uso de matrices ... 90
6.10.2. Programa lectura y escritura de matrices ... 91
6.10.3. Programa Suma de Diagonales y Transversales ... 92
6.10.4. Programa de Diagonal ... 93
6.10.5. Programa de Copas ... 93
Lección 28 6.10.6. Programa Simulación de un Inventario ... 96
6.10.7. Programa Simulación de un Parqueadero ... 97
Lección 29 6.11. Ejemplo Cola 1 ... 99
6.12. Ejemplo Cola 2 ... 101
6.13. Ejemplo Cola 4 ... 104
6.14. Ejemplo Cola 4 Archivo ... 107
6.15. Ejemplo Lista ... 111
Lección 30 6.16. Ejemplo Lista Circular ... 113
6.17. Ejemplo Lista y Cola... 115
6.18. Ejemplo Lista y Pila ... 117
6.19. Ejemplo Multilista ... 120
6.20. Ejemplo Pila ... 121
6.21. Ejemplo Arbol Binario ... 125
6.22. Ejemplo Arbol Binario ... 127
UNIDAD 3. CLASES Y HERENCIA EN LA PROGRAMACION ORIENTADA A OBJETOS CAPITULO 7. CLASES BASICAS EN LA POO Lección 31 7.1 Conceptos Básicos ... 133
7.1.1 Concepto de Clase ... 133
7.1.2 Características Importantes De Las Clases: ... 134
7.1.3 Concepto de Interface ... 134
7.2. Ejemplo De Definición De Una Clase ... 135
7.3. Variables miembro ... 136
7.3.1 Variables miembro de objeto ... 137
7.3.2 Variables Finales ... 138
7.4 Abstracción ... 139
7.5 Encapsulado ... 140
7.6 Arreglos y cadenas ... 140
7.7 Flujo de E/S en java ... 141
Lección 32 7.8. Gestión De Excepciones Y Errores ... 142
7.8.1 Tipos de excepciones ... 142
7.8.1.1 Herencia de excepciones Java ... 143
7.8.2.1 Manejo de excepciones: try - catch – finally ... 144
7.8.2.2. Lanzamiento de excepciones: throw – throws ... 145
7.8.2.3 Ejemplo de gestión de excepciones ... 145
7.8.3 Los métodos ... 148
Lección 33 7.8.4 La instanciación de las clases: Los objetos ... 149
7.8.4.1 Referencias a Objeto e Instancias ... 149
7.8.4.2 Constructores ... 150 7.8.4.3 El operador new ... 151 Lección 34 7.8.5. Acceso al objeto ... 152 7.8.5.1 El operador punto (.) ... 152 7.8.5.2 La referencia this ... 153 Lección 35 7.8.6. La destrucción del objeto ... 154
7.8.6.1 La destrucción de los objetos ... 154
7.8.6.2 La destrucción por defecto: Recogida de basura ... 154
7.8.6.3 La destrucción personalizada: finalize ... 155
7.8.7 Herramientas De Java ... 155
7.8.7.1 Paquetes de utilidades ... 156
7.8.7.2 Paquetes para el desarrollo gráfico ... 156
7.8.7.3 Paquetes para el desarrollo en red ... 156
7.8. ACTIVIDADES COMPLEMENTARIAS ... 156 Lección 36 APITULO 8. HERENCIA 8.1 La Herencia ... 158 8.2 Jerarquía ... 158 8.3 Herencia múltiple ... 159 8.4 Declaración ... 159 Lección 37 8.5 Limitaciones en la herencia ... 160 8.6. La clase Object ... 161 Lección 38 8.7 Extensión De Clases ... 162
8.7.1 Composición De Objetos Extendido ... 162
8.7.1.1subclase ... 162
8.7.2 Relación de tipo de herencia ... 163
Lección 39 8.7.2.1 Métodos ... 163
Lección 40 8.7.2.2 Sobrecarga De Método ... 165
CAPITULO 9. EXTENSIÓN DE CLASES Lección 41 9.1. Applest Y Web ... 167
9.1.1 Applets ... 167
9.1.2 HTML para Java ... 167
9.1.3 Protocolos Para Trabajo En La Red ... 167 Lección 42
9.1.4 Que Es Un Applet ... 168
9.1.4.1 Consideraciones sobre la seguridad en las applets ... 169
Lección 43 9.1.5 La Clase Applet ... 170
9.1.5 .1 Situación de la clase Applet en la API de Java ... 170
9.1.5.2 Métodos del ciclo de vida ... 170
Lección 44 9.1.6 La Clase Url ... 172
9.1.7 Inclusión de la applet en una página Web ... 172
9.1.7.1 Obtención de los parámetros de la applet ... 173
9.1.7.2 Obtención de información sobre una applet ... 174
9.1.7.3 Manipulación del entorno de una applet ... 174
Lección 45 9.1.8 Ejemplo De Construcción De Una Applet ... 175
9.1.8.1 Código ... 175
9.1.8.2 Ejecución ... 176
9.2 ACTIVIDADES COMPLEMETARIAS ... 176
CAPITULO 10. BIBLIOGRAFIA 10.1. Bibliografia ... 178
UNIDAD 1. INTRODUCCION A LA PROGRAMACION ORIENTADA A OBJETOS
Leección
CAPÍTULO 1. CONCEPTOS BASICOS ORIENTADOS A OBJETOS
1.1. (Tomado del libro Programación de Computadores de José Cárcamo Sepúlveda, Ediciones UIS)
Hoy por hoy es evidente que la orientación a objetos es el término más corriente en diversos entornos con actividades comerciales, industriales, de servicios y académicos. A través de esta técnica se logra la optimización en tareas concernientes a las fases de desarrollo de software como en el diseño, desarrollo y mantenimiento del software. Esto ha permitido ofrecer soluciones con larga opción de usabilidad atacando problemas concernientes a la denominada crisis del software. Lo anterior pensado teniendo en cuenta la existencia de procesos imprescindibles hoy en día como lo son la reutilización de código y su portabilidad.
La Programación Orientada a Objetos se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como una característica fundamental del mismo.
Quizá al hablar de objetos se nos venga a la cabeza el cuento de los objetos voladores no identificados, aquí hablaremos de objetos pero no serán solo voladores, y seguro serán siempre plenamente identificados.
La Programación Orientada a Objetos modela el mundo en términos de objetos, eventos y responsabilidades. Existen objetos que contienen datos y métodos y eventos que activa procedimientos , que pueden modificar el estado de los objetos. En los lenguajes orientados a objetos un programa, es un apropiado encadenamiento de mensajes entre distintos objetos, previamente instanciados de las clases a las que pertenecen.
1.2. Que es un objeto?
Según el diccionario, un objeto es cualquier cosa que se ofrece a la vista y afecta los sentidos. Es así como podemos ver que el mundo real que nos rodea es un conjunto de objetos.
Si miramos a nuestro alrededor podemos observar plantas, animales, personas, cosas, etc. Estos son objetos tangibles. Existen otros que no son tangibles, pero somos conscientes de que existen, por ejemplo “un mes del ano”, “una hora de una cita”, un sentimiento, una profesión etc.
Lección 2
1.3. Cada objeto tiene un conjunto de características o atributos que lo hacen diferente a los demás.
Por ejemplo una planta difiere notablemente de un animal y de un edificio. Cada uno de ellos presentan características y comportamientos muy diferentes, mas aun aunque dos objetos sean exactamente iguales, son distintos entre si, por ejemplo dos carros recién salidos de la fabrica, que tienen la misma marca, el mismo modelo, la misma línea, las mismas características, son dos objetos distintos pues cada uno tiene una identificación diferente, aunque pertenecen a la misma clase.
1.4. Inicialmente podríamos decir que un objeto es algo que tiene atributos y comportamientos propios.
Una planta es un ser viviente, vegetal que a primera vista esta construido por hojas, tallos, frutos, raíz, etc. Además respira por sus hojas, se alimenta por su raíz, elabora clorofila etc. Son algunas de las características y comportamiento que podemos percibir superficialmente de una planta.
Un diccionario es un libro especial que contiene un conjunto de palabras y definiciones, también podemos encontrar en el graficas, tablas, ilustraciones, etc. Y su utilidad la percibimos cuando necesitamos consultar alguna palabra, leer su significado, verificar su ortografía, o de pronto investigar sobre algún tema especifico. Lección 3
¿Por ejemplo el amor? ¿La alegría?. Quizá nos sea difícil en los objetos abstractos, pero de una u otra forma lograríamos hacerlo. Desde el punto de vista computacional es posible representar lógicamente cualquier objeto del mundo real.
Para una solución software un objeto es un elemento especial de información que se construye a partir de una estructura de datos y una estructura funcional.
La estructura funcional opera directamente sobre la estructura de datos y esta a su vez solo puede ser manipulada por la estructura funcional del mismo objeto.
En la programación estructurada la estructura de datos es totalmente independiente de la parte funcional o procedimental; es mas podríamos afirmar que lo único estructurado en la “programación estructurada” son los procedimientos pero los datos están muy aislados.
La programación orientada a objetos se acerca mas al mundo real estructurando en un mismo elemento de información datos y procedimientos.
1.6. Tipo abstracto de datos
En la terminología de organización de la información muchas veces se manejan los términos “estructura de datos” y “tipo abstracto de datos” como una misma cosa . Sin embargo, para muchos autores, existe una diferencia entre los dos términos. Aparece entonces un nuevo elemento de información que se denomina “tipo abstracto de datos”.
Un tipo abstracto de datos contienen una estructura de datos propia y un conjunto de operaciones o métodos autorizados para manipular la estructura de datos.
Para representar a un objeto recurrimos a un tipo abstracto de datos. Por ejemplo tomemos un objeto del mundo real cotidiano que nos rodea. Imaginemos un objeto RELOJ, encontramos en el unas características a nivel de datos (estructuras de datos) y unas características de comportamiento (características funcionales).
Lección 4
1.7. Características de datos: Por ejemplo hora, minutos y segundos
Características funcionales: Por ejemplo mostrar la hora, actualizar la hora y siendo mas ambiciosos mostrar la hora en segundos, mostrar la hora en minutos o sumar y restar horas.
ESTRUCTURA DE DATOS
ESTRUCTURA FUNCIONAL
Representemos este objeto del mundo real como un tipo abstracto de datos. Quedaría de la siguiente forma:
ESTRUCTURA DE DATOS Hora Minutos Segundos ESTRUCTURA FUNCIONAL Leer hora Mostrar hora
Mostrar hora en segundos Mostrar hora en minutos Sumar hora
Restar hora
1.8. Para representar el objeto anterior debemos considerar tres aspectos
1. ¿Cómo representar la estructura de datos?
Identificar las características del objeto a nivel de datos. Horas.
Minutos. Segundos
2. ¿Cómo representar su comportamiento?
Identificar las operaciones o procesos a efectuar sobre los datos Leer hora
Mostrar hora
3. ¿Cómo comunicarnos con el objeto?
Para comunicarnos con el objeto debemos enviarle un mensaje. Lección 5
1.9. Que es un mensaje?
Según el diccionario, un mensaje es un encargo de decir o llevar una cosa. Más puntualmente, podemos definir un mensaje como el llamado que se hace a un objeto para que ejecute una de sus operaciones. Para que el objeto funcione se le debe enviar un mensaje adecuado, que sea identificado por el mismo objeto.
En el ejemplo del reloj podemos enviarle un mensaje para que nos muestre la hora: MENSAJE: “Mostrar hora”, es un mensaje identificable por el objeto por que puede invocar una operación propia del mismo. MENSAJE: “Mostrar fecha”, resulta desconocido para el objeto por que no existe ninguna operación asociada a el.
Los objeto ofrecen al mundo que lo rodea una puerta de entrada que es la que permite determinar si el mensaje es adecuado o no. A esta puerta de entrada se le denomina “interfaz de objeto”
El mensaje llega a la interfaz de objeto solicitando una operación y si este se ajusta a una forma de llamado conocida, el objeto actúa.
1.10. Beneficios de la POO (tomado de monografías.com)
Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfaces hombre-máquina "a-la-Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta conceptual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extensibles y a partir de componentes reusables. Esta reusabilidad del código
disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.
1.11. Problemas derivados de la utilización de OOP en la actualidad (tomado de monografías.com)
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:
1.11.1. Curvas de aprendizaje largas.
Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.
1.11.2. Dependencia del lenguaje.
A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia múltiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importantes.
1.11.3. Determinación de las clases.
Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.
En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de micro procesamiento, potencia y tamaño de la memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente. Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debería existir una metodología fácil de aprender e independiente del lenguaje, y fácil de reestructurar que no drene la performance del sistema.
CAPITULO 2. INTRODUCCIÓN Y ELEMENTOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A OBJETOS (POO)
Lección 6
2.1. Introducción
Actualmente una de las áreas más importantes en la industria y el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo del software: la falta de portabilidad del código y reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características básicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos de los lenguajes pueden cumplir uno o dos de estos puntos, pero es muy difícil que se cumplan los tres, el inconveniente mas complicado de diseñar es la herencia.
El concepto de programación orientada a objetos (POO) no es nuevo, lenguajes clásicos como SmallTalk se basan en ella. Dado que la POO, se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos. Un lenguaje se dice que está basado en objetos si soporta como una característica fundamental del mismo.
El elemento fundamental de la POO es, como su nombre lo indica, el objeto.
Podemos definir un objeto como un conjunto complejo de datos y programas que poseen una estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.
Básicamente la POO permite a los programadores escribir software, de forma que esté organizado en la misma manera que el problema que trata de modelar. Los lenguajes de programación convencionales son poco más que una lista de acciones a realizar sobre un conjunto de datos en una determinada secuencia. Si en algún punto del programa modificamos la estructura de los datos o la acción realizada sobre ellos, el programa cambia.
2.2 ¿Porqué POO?
Es una manera de pensar, otra manera de resolver un problema; lo más reciente en metodologías de desarrollo de software. Es un proceso mental humano aterrizado en una computadora.
Antes se adecuaba el usuario al entendimiento de la computadora. Actualmente, se le enseña a la computadora a entender el problema.
La Orientación a Objetos es un paradigma, es decir, es un modelo para aclarar algo o para explicarlo. La Orientación a Objetos es el paradigma que mejora el diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo del desarrollo del software:
La falta de portabilidad del código, su reusabilidad, la modificación (que antes era difícil de lograr), ciclos de desarrollo largo, técnicas de programación no intuitivas. La Orientación a Objetos está basada en los tres métodos de organización que utilizamos desde la infancia; entre un objeto y sus atributos (automóvil > marca, color, número de llantas, etc.); Entre un objeto y sus componentes donde incluso otros objetos pueden formar parte de otros objetos (agregación) (camión > motor, parabrisas, llantas); entre un objeto y su relación con otros objetos (camión > vehículos automotores; una bicicleta no entraría en esta relación).
La metodología del software orientado a objetos consiste en:
Saber el espacio del problema Realizar una abstracción
Crear los objetos (espacio de la solución)
Instanciarlos (esto es, traerlos a la vida)
Dejarlos vivir (ellos ya saben lo que tienen que hacer)
Las herramientas de programación orientadas a objetos ayudan a manejar la complejidad. Desarrollar software que sea fácil de utilizar hace que sea muy compleja su construcción.
El diseño del nuevo software se enfoca a complejas interfaces de usuarios, sistemas de manejo de ventanas, y programas multitarea están haciendo que el software sea cada vez mas complejo. Las herramientas enfocadas a objetos facilitan la comprensión de esta complejidad, la estructuración orientada a objetos reduce el número de conexiones entre los componentes del sistema, obligar a que los objetos se comuniquen a través de una interfaz pública estrecha hace más fácil aislar los errores ocultos y determinar cuales son los métodos responsables de los errores ocultos que ocurran.
Los objetos mismos protegen los datos privados de modificaciones no deseadas. La definición explicita de un protocolo de comunicación permite a compiladores e intérpretes advertir a los usuarios acerca de los accesos ilegales e incluso impedir la modificación no deseada de los componentes del sistema.
Una de las mayores ventajas de una estructura orientada a objetos es el mapeo directo de los objetos en el dominio del problema a los objetos en el programa.
Este mapeo directo es una consecuencia de tener una estructura basada en objetos. Si la programación se considera una simulación, resulta mucho más fácil seleccionar objetos de un mundo simulado que desarrollar una solución de programación basada completamente en procedimientos y acciones.
La orientación a objetos surgió de la necesidad de simular sistemas de forma sencilla, no solo de información, si no de cualquier otro tipo, sin importar el modo de implantación.
2.3 ¿Que es la POO?
La Programación Orientada a Objetos (POO ú OOP según siglas en inglés) es una metodología de diseño de software y un paradigma de programación que define los programas en términos de "clases de objetos", objetos que son entidades que combinan estado (es decir, datos) y comportamiento (esto es, procedimientos o métodos). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que se comunican entre ellos para realizar tareas. Esto difiere de los lenguajes procedimentales tradicionales, en los que los datos y los procedimientos están separados y sin relación. Estos métodos están pensados para hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.
Otra manera en que esto es expresado a menudo, es que la programación orientada a objetos anima al programador a pensar en los programas principalmente en términos de tipos de datos, y en segundo lugar en las operaciones ("métodos") específicas a esos tipos de datos. Los lenguajes procedimentales animan al programador a pensar sobre todo en términos de procedimientos, y en segundo lugar en los datos que esos procedimientos manejan.
Los programadores que emplean lenguajes procedimentales, escriben funciones y después les pasan datos. Los programadores que emplean lenguajes orientados a objetos definen objetos con datos y métodos y después envían mensajes a los objetos diciendo que realicen esos métodos en sí mismos.
Algunas personas también diferencian la POO sin clases, la cual es llamada a veces programación basada en objetos.
Hay un cierto desacuerdo sobre exactamente que características de un método de programación o lenguaje le califican como "orientado a objetos", Término de Programación Orientada a Objetos indica más una forma de diseño y una metodología de desarrollo de software que un lenguaje de programación, ya que en realidad se puede aplicar el Diseño Orientado a Objetos (En inglés abreviado OOD, Object Oriented Design), a cualquier tipo de lenguaje de programación.
El desarrollo de la POO empieza a destacar durante la década de lo 80 tomando en cuenta la programación estructurada, a la que engloba y dotando al programador de nuevos elementos para el análisis y desarrollo de software.
Se puede definir POO como una técnica o estilo de programación que utiliza objetos como bloque esencial de construcción.
Los objetos son en realidad como los tipos abstractos de datos. Un TAD es un tipo definido por el programador junto con un conjunto de operaciones que se pueden realizar sobre ellos. Se denominan abstractos para diferenciarlos de los tipos de datos fundamentales o básicos.
Lección 7
2.4 Ventajas de POO
La OOP proporciona las siguientes ventajas sobre otros lenguajes de programación
Uniformidad. Ya que la representación de los objetos lleva implica tanto el análisis
como el diseño y la codificación de los mismos.
Comprensión. Tanto los datos que componen los objetos, como los procedimientos
que los manipulan, están agrupados en clases, que se corresponden con las estructuras de información que el programa trata.
Flexibilidad. Al tener relacionados los procedimientos que manipulan los datos con
los datos a tratar, cualquier cambio que se realice sobre ellos quedará reflejado automáticamente en cualquier lugar donde estos datos aparezcan.
Estabilidad. Dado que permite un tratamiento diferenciado de aquellos objetos que
permanecen constantes en el tiempo sobre aquellos que cambian con frecuencia permite aislar las partes del programa que permanecen inalterables en el tiempo.
Reusabilidad. La noción de objeto permite que programas que traten las mismas
estructuras de información reutilicen las definiciones de objetos empleadas en otros programas e incluso los procedimientos que los manipulan. De esta forma, el desarrollo de un programa puede llegar a ser una simple combinación de objetos ya definidos donde estos están relacionados de una manera particular.
Reutilización. Las clases se construyen a partir de otras clases. Sistemas más fiables.
Proceso de desarrollo apropiado. Desarrollo más flexible.
Modelos que reflejan mejor la realidad.
Mejor independencia e interoperatividad de la tecnología. Mejor informática distribuida en cliente – servidor.
Bibliotecas de clases comerciales disponibles. Mejores relaciones con los clientes.
Mejor calidad del producto de software terminado. Lección 8
2.5. Desventajas de la tecnología orientada a objetos.
A pesar de que las ventajas de la programación orientada a objetos superan a las limitaciones de la misma, podemos encontrar algunas características no deseables en ésta.
Limitaciones para el programador. No obstante que la tecnología orientada a objetos no es nueva, un gran porcentaje de programadores no están familiarizados con los conceptos de dicha tecnología. En otras palabras, la lógica de la programación estructurada sigue siendo predominante en la mayoría de los desarrolladores de software, después de haber revisado de forma breve los principios de la programación orientada a objetos, nos es claro que en ésta se requiere una lógica de pensamiento totalmente diferente a la lógica comúnmente utilizada para la programación estructurada.
Tamaño excesivo en las aplicaciones resultantes. La gran mayoría de los equipos de cómputo cuentan con capacidades tanto de almacenamiento como de memoria lo suficientemente buena como para ejecutar la mayoría de las aplicaciones que puedan desarrollarse con la tecnología orientada a objetos, sin embargo existen casos en los que lo anterior no se cumple.
Una de las desventajas de la programación orientada a objetos es que cuando se heredan clases a partir de clases existentes se heredan de forma implícita todos los miembros de dicha clase aun cuando no todos se necesiten, lo que produce aplicaciones muy grandes que no siempre encajan en los sistemas con los que se disponga.
Velocidad de ejecución. Esto tiene que ver, en cierto modo, con el punto anterior, una aplicación innecesariamente pesada en muchas ocasiones es más lenta de ejecutar que una aplicación conformada únicamente por los módulos necesarios.
Lección 9
2.6 Evolución de la programación
POO (Programación Orientada a Objetos)es un importante conjunto de técnicas que se pueden utilizar para hacer el desarrollo de programas más eficientes mientras se mejora la facilidad de los programas resultantes. En esencia, POO es un nuevo medio de enfocar el trabajo de programación. Sin embargo, a fin de comprender lo que es la POO, es necesario comprender sus raíces. Así pues, comenzaremos por examinar la historia del proceso de programación analizada cómo evolución POO y deduciendo, en consecuencia, por qué es tan importante este concepto.
2.6.1. Programación lineal.
Los lenguajes de programación lineal (BASIC, COBOL Y FORTRAN) no tenían facilidad para reutilizar el código existente de programas. De hecho se duplicaban segmentos de software cada vez más en muchos programas. Los programas se ejecutaban en secuencias lógicas, haciendo la lógica difícil de comprender. El control de programas era difícil y se producían continuos saltos a lo largo del referido programa. Aún más, los lenguajes lineales no tenían capacidad de controlar la visibilidad de los elementos llamados datos.
El soporte más elemental de la programación Modular llegó con la aparición de la subrutina. Una subrutina ha creado una secuencia de instrucciones a las que se les da un nombre independiente; una vez que se ha definido, la subrutina se puede ejecutar simplemente incluyendo el nombre del programa siempre que se requiera. Las subrutinas proporcionan una división natural de las tareas; diferentes programas utilizan. Aunque las subrutinas proporcionan el mecanismo básico de la programación Modular, se necesita mucha disciplina para crear software bien estructurado. Sin esta disciplina, es fácil escribir programas compilados y tortuosos difíciles de modificar y comprender, así como imposible de mantener. Esta ha sido la panorámica durante muchos años en el desarrollo del software.
2.6.3. Programación Estructurada.
Un concepto importante en campo de la programación Estructurada: Abstracción, ya que la Abstracción se puede definir como la capacidad de examinar algo sin preocuparse de los detalles internos. En un programa estructurado, es suficiente conocer que un procedimiento sea fiable, para que se pueda utilizar sin tener que conocer cómo funciona su interior. Esto se conoce como una Abstracción funcional y es el núcleo de la programación estructurada. Hoy casi todos los lenguajes de programación tienen construcciones que facilitan la programación estructurada.
Lección 10
2.7. Comparación entre la Programación orientada a Objetos y la programación estructurada.
2.7.1. Paradigma Estructurado
La Programación estructurada fija su atención en el conjunto de acciones que manipulan el flujo de datos, mientras que la POO se fija en la interrelación que existe entre los datos y las acciones a realizar con ellos.
Descomposición funcional: el sistema es considerado una unidad funcional que se disgrega en procesos
El resultado del proceso de abstracción para la solución de un problema macro lo constituyen pequeños subprogramas
Un problema macro se subdivide en unidades más pequeñas llamadas procesos, estos se pueden distribuir entre diferentes personas que se vean involucradas en la solución de un problema y así efectuar los desarrollos de software de una manera más rápida y eficiente. Figura 1.1 Programación Estructurada
Los procesos son la parte central de este modelo pues a partir de estos se manejan las variantes (datos) que solucionarán el problema.
Generalmente se manejan muchos procesos lo cual hace largos códigos. El mantenimiento de los desarrollos deben efectuarse minuciosamente.
Los procedimientos empleados en una aplicación pueden reutilizarse teniendo cuidado en el manejo de los datos.
Las operaciones se ajustan a las características propias de los lenguajes procedimentales.
Los procesos que se modelan en el desarrollo de un problema plasman las operaciones necesarias para resolverlo
Los procesos son la parte central de este modelo pues a partir de estos se manejan las variantes (datos) que solucionarán el problema.
Generalmente se manejan muchos procesos lo cual hace largos códigos. El mantenimiento de los desarrollos deben efectuarse minuciosamente.
Los procedimientos empleados en una aplicación pueden reutilizarse teniendo cuidado en el manejo de los datos.
Las operaciones se ajustan a las características propias de los lenguajes procedimentales.
Los procesos que se modelan en el desarrollo de un problema plasman las operaciones necesarias para resolverlo
2.7.2 Paradigma Orientado a Objetos
Descomposición en objetos. El sistema es considerado un objeto o conjunto de objetos. Los cuales son el resultado del proceso de abstracción para la solución del problema macro.
Dado que un problema macro puede ser dividido en objetos, estos pueden ser tratados por diferentes personas que luego lo integraran para dar la solución final.
Los datos (estados) son la parte central del modelo y los métodos que los modifican muestran el comportamiento del objeto.
El mantenimiento de programas y aplicaciones generalmente son fáciles de realizar .
Los objetos que se modelan en el desarrollo de un sistema se ajustan a la realidad que representa el problema, este puede representare como un objeto o conjunto de objetos abstractos.
El modelo orientado a objetos no es una técnica de programación sino un medio de plasmar el mundo real.
Adición: R = A + B, R =(a1 + b1, a2 + b2, a3 + b3) Producto Punto: R = A . B, R =(a1 .b1 + a2 .b2 + a3 .b3)
Producto Cruz: R = A x B, R =(a2*f3-a3*b2, a3*b1-a1*b3, a1*b2- a2*b1) Producto por escalar: R = k A, R = ( ka1, ka2, ka3 )
Normal: R = /R/I, R = Raíz cuadrada de (A * A)
Figura 1.4 Objeto
2.7.2.1.Ventajas del Modelo orientado a objetos con respecto al modelo estructurado
Un modelo de objetos es más cercano a la realidad que un modelo funcional.
Un desarrollo realizado con el modelo orientado a objetos es más fácil de mantener y de reutilizar.
El modelo orientado a objetos evita la redundancia en los procesos luego los códigos son más entendibles y resumidos.
La integridad que dan los objetos a los datos evita ambigüedades en su uso, dando mayor seguridad en los resultados.
El modelo orientado a objetos facilita la integridad de módulos que hallan sido realizados por separado sin correr riesgos en el manejo de los datos.
Autoevaluación
2.8 ACTIVIDADES COMPLEMENTARIAS Pate Uno:
1. Investigue la diferencia entre la POO y la Programación estructurada? 2. Que es la POO? Y cuales son sus ventajas?
3. Que es una clase y Que es un objeto? 4. Explique cual es la estructura de un objeto?
5. Realice un ejemplo de manera grafica en donde se identifiquen los elementos de una clase y un objeto.
6. Ver Capitulo 9 Guia de Laboratorios para desarrollar en los laboratorios del CEAD o CERES respectivos
Parte Dos:
Realizar los ejercicos complementarios de Laboratorios de la Guia de Laboratotios y Consultar Bibliografia de Libros Virtual de la Unad y otros Autores 1. Autor: Deitel y Deitel Introducción DOO con UML y los Patrones de Diseño JDBC tm, SERVLETS, JSP tm Editorial Pearson Prentice Hall Quinta Edición, 2. David Arnow Gerald Weiss Introducción a la Programación con Java tm Actualización a la Versión 2 de Java Editorial Addison Wesley 3. Fcd Javier Ceballos Java 2 Curso de Programación 2 Edición Editorial Alfaomega Ra-Ma 4. Agustin Froute Java 2 Manual Usuario tutorial 3 Edición Editorial Alfaomega Ra-Ma 5. Herbert shildt Fundamentos de Programación Java 2 Editorial Mc Graw Hill . para conocer el lenguaje de programación JAVA ya que están resueltos solo los puede digitar compilar y ejecutar en la casa o laboratorio de su correspondiente CEAD o CERES.
Lección 11
CAPITULO 3. PROPIEDADES BÁSICAS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS
La programación orientada a objetos, ha tomado las mejores ideas de la programación estructurada y los ha combinado con varios conceptos nuevos y potentes que incitan a contemplar las tareas de programación desde un nuevo punto de vista. La programación orientada a objetos, permite descomponer más fácilmente un problema en subgrupos de partes relacionadas del problema.
Entonces, utilizando el lenguaje se pueden traducir estos subgrupos a unidades auto contenidas llamadas objetos.
El término Programación Orientada a Objetos (POO), hoy en día ampliamente utilizado, es difícil de definir, ya que no es un concepto nuevo, sino que ha sido el desarrollo de técnicas de programación desde principios de la década de los setenta, aunque sea en la década de los noventa cuando ha aumentado su difusión, uso y popularidad. No obstante, se puede definir POO como una técnica o estilo de programación que utiliza objetos como bloque esencial de construcción.
Un objeto es una unidad que contiene datos y las funciones que operan sobre esos datos. A los elementos de un objeto se les conoce como miembros; las funciones que operan sobre los objetos se denominan métodos y los datos se denominan miembros datos.
Lección 12
3.1 Abstracción
Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando los están, una variedad de técnicas son requeridas para ampliar una abstracción.
La abstracción es una especificación del sistema que enfatiza sobre algunos de los detalles o propiedades del mismo mientras suprime a otros. Una buena abstracción es aquella que enfatiza sobre detalles significativos al lector y al usuario y suprime detalles que son al menos por el momento irrelevantes o que causan distracción.
Existen cuatro tipos de abstracciones:
La primera es la abstracción de entidades; este tipo de abstracción representa una entidad ya sea del dominio del problema o del dominio de la solución.
El segundo tipo de abstracción es la abstracción de acciones, es la abstracción de comportamiento, esta abstracción proporciona un conjunto especializado de operaciones y todas ellas desempeñan funciones del mismo tipo.
El tercer tipo de abstracción es el de maquinas virtuales, este tipo de abstracción agrupa operaciones virtuales utilizadas por un nivel superior de control u operaciones que utilicen un conjunto de operaciones de nivel inferior. Por ejemplo, una abstracción que utilice el código "x" cuando la aplicación se ejecute en Latinoamérica, o utilice el código "y" cuando se ejecute el Norteamérica.
El último tipo de abstracción es el de coincidencia, que almacena un conjunto de operaciones que no tienen relación entre sí, esto es, toma actividades que aparentemente no tienen una relación como las clases hombre (con métodos como come(), camina(), etc.), las clases transporte aéreo (volar()) y ave (volar()) y creamos una subclase de hombre llamada superhombre que come(), camina() y vuela(); esto se logra tomando comportamientos que no tienen que ver entre sí y no se atribuyen a la herencia sino a la interfaz.
Padre Interfaz \ / Hijo
Por definición una interfaz es abstracta, por lo tanto no tiene un comportamiento, sólo la declaración de este.
Lección 13
3.2 Encapsulación
También llamada "ocultación de la información", esto asegura que los objetos no pueden cambiar el estado interno de otros objetos de maneras inesperadas; solamente los propios métodos internos del objeto pueden acceder a su estado.
Cada tipo de objeto expone una interfaz a otros objetos que especifica cómo otros objetos pueden interactuar con él. Algunos lenguajes resaltan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción.
La encapsulación protege los atributos que conforman al objeto, y permite o niega información al público. Con el encapsulamiento, se consigue ocultar información y
ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales, típicamente la estructura de un objeto se encuentra oculta y la implantación de sus métodos es visible.
Para el caso del termómetro tal vez sólo se requieren 3 métodos: activarlo, desactivarlo y pedirle la temperatura.
Un objeto es la abstracción de algo que forma parte del dominio del problema reflejando las posibilidades de un sistema para mantener la información sobre él. Representa una entidad real o abstracta con un papel bien definido dentro de nuestro mundo y con dos características que son sus atributos y su comportamiento.
Ejemplos de objetos pueden ser un celular, lentes, pluma, computadora, pizarrón, perro, etc.
Los objetos se componen de atributos o variables que aclaran el estado del objeto. Los atributos de un objeto, bicicleta, podrían ser el número de llantas que tiene (estado 2) el numero de marchas (estado 4 si es de velocidades), numero de asientos (estado uno), velocidad instantánea.
Para alterar el estado de un objeto se necesita invocar un método. Este método es algo que el objeto sabe y por lo tanto define su comportamiento.
Bicicleta.dameTuvelocidadactual() -entrega 0 Bicicleta.avanza(10) -modifico su velocidad
Bicicleta.dameTuvelocidadactual()-entrega valor distinto de cero.
La encapsulacion es una técnica que permite localizar y ocultar los detalles de un objeto. La encapsulación previene que un objeto sea manipulado por operaciones distintas de las definidas. La encapsulación es como una caja negra que esconde los datos y solamente permite acceder a ellos de forma controlada.
Las principales razones técnicas para la utilización de la encapsulación son:
1) Mantener a salvo los detalles de representación, si solamente nos interesa el comportamiento del objeto.
2) Modificar y ajustar la representación a mejores soluciones algorítmicas o a nuevas tecnologías de software.
Lección 14
3.3 Modularidad
Proceso de crear partes de un todo que se integran perfectamente entre sí para que funcionen por un objetivo general, y a las cuales se les pueden agregar más componentes que se acoplen perfectamente al todo, o extraerle componentes sin afectar su funcionamiento. En el caso que se requiera actualizar un módulo, no hay necesidad de hacer cambios en otras partes del todo. Un ejemplo clásico es un conjunto de módulos que, al integrarlos conforman un armario, el cual puede agregarle más funcionalidad si se le agregan más módulos, o al contrario.
También se puede cambiar su finalidad si se acomodan esos módulos para darle otro objetivo: volverlo una mesa.
Esto ayuda a la descomposición de problemas en subproblemas, es decir, a la solución de problemas por composición de soluciones a subproblemas
Modularidad es el atributo del software que permite a un programa ser manejable intelectualmente. G. Myers
La arquitectura del software implica la división de éste en componentes identificables y tratables por separado, denominados módulos, que están integrados para satisfacer los requisitos del programa.
Un software monolítico no puede ser entendido fácilmente por un solo usuario. El número de caminos de control, ámbito de referencia, número de variables y la complejidad global harían su comprensión casi imposible.
Para ver la importancia de la modularidad, considérense los siguientes argumentos basados en observaciones llevadas a cabo: Sea C(x) una función que define la complejidad percibida de un problema x, y E(x) una función que defina el esfuerzo (en tiempo) requerido para solucionar el problema x.
Para dos problemas P1 y P2, si
C(P1) > C(P2) se sigue que
E(P1) > E(P2) Otra interesante característica se ha descubierto durante la experimentación en la resolución de problemas, y es:
C(P1 + P2) > C(P1) + C(P2) se sigue que E(P1 + P2) > E(P1) + E(P2)
Es más fácil resolver un problema complejo cuando se rompe en piezas manejables. Lección 14
3.4 Jerarquía
La mayoría de las personas ve de manera natural nuestro mundo como objetos que se relacionan entre sí de una manera jerárquica. Por ejemplo, un perro es un mamífero, y los mamíferos son animales, y los animales seres vivos...
Del mismo modo, las distintas clases de un programa se organizan mediante la jerarquía. La representación de dicha organización da lugar a los denominados árboles de herencia:
Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre. Así se simplifican los diseños y se evita la duplicación de código al no tener que volver a codificar métodos ya implementados.
Al acto de tomar propiedades de una clase padre se denomina heredar. Lección 5
3.5 Polimorfismo
Las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del referente. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
En programación orientada a objetos se denomina polimorfismo a la capacidad del código de un programa para ser utilizado con diferentes tipos de datos u objetos. También se puede aplicar a la propiedad que poseen algunas operaciones de tener un comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican.
El concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse y/o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado.
Se puede clasificar el polimorfismo en dos grandes clases:
Polimorfismo dinámico (o polimorfismo ad hoc) es aquél en el que el código no
incluye ningún tipo de especificación sobre el tipo de datos sobre el que se trabaja. Así, puede ser utilizado a todo tipo de datos compatible.
Polimorfismo estático (o polimorfismo paramétrico) es aquél en el que los tipos a
los que se aplica el polimorfismo deben ser explicitados y declarados uno por uno antes de poder ser utilizados.
El polimorfismo dinámico unido a la herencia es lo que en ocasiones se conoce como programación genérica.
3.6 Herencia
Organiza y facilita el polimorfismo y la encapsulación permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y las clases en árboles o enrejados que reflejan un comportamiento común.
La herencia es uno de los mecanismos de la programación orientada a objetos, por medio de la cual una clase se deriva de otra de manera que extiende su funcionalidad. Una de sus funciones más importantes es la de proveer polimorfismo .
La herencia en la POO permite a una clase heredar las propiedades de una clase de objetos, donde la clase padre sirve como patrón a la clase derivada. si un objeto hereda sus atributos de un único padre, esto recibe el nombre de herencia simple, y si hereda atributos de múltiples padres es herencia múltiple, la ventaja de la herencia es permitir la reutilización de código.
Para realizar herencia se debe tener en cuenta dos aspectos importantes: la clase base y la clase derivada donde la clase base define todas las cualidades que serán heredadas por cualquier clase y la clase derivada hereda las características generales y añade a esta de su propia clase.
Utilizando la herencia, un objeto sólo necesita definir aquellas cualidades que lo hacen único dentro de una clase. Este objeto puede heredar sus atributos generales de su padre. Por lo tanto la herencia es el mecanismo que le permite a un objeto ser una instancia específica de un caso más general analicemos el proceso de un animal. Por ejemplo al hacer una descripción de los animales de forma abstracta, se puede decir que estos tiene atributos tales como: tamaño, inteligencia, y el tipo de esqueleto. Los animales tienen diferentes clase de comportamiento esta puede ser una definición de la clase de los animales.
La herencia interactúa con el encapsulado. Si una clase dada encapsula algunos atributos, entonces la cualquier clase tendrá los mismos atributos.
3.6.1 Tipos de herencia
Herencia sencilla: Un objeto puede extender las características de otro objeto y de ningún otro, es decir, solo puede tener un padre.
Herencia múltiple: Un objeto puede extender las características de uno o más objetos, es decir, puede tener varios padres. En este aspecto hay discrepancias entre los diseñadores de lenguajes. Algunos de ellos han preferido no admitir la herencia múltiple por las posibles coincidencias en nombres de métodos o datos miembros. Por ejemplo C++ admite herencia múltiple, Java y Ada sólo herencia simple.
Si una clase cualquiera tiene más de un ancestro directo en la jerarquía de clases, se considera que existe herencia múltiple. En términos concretos, una instancia de objeto de la clase hija, poseerá todos los atributos y métodos de sus clases ancestro.
Autoevaluación
3.7 ACTIVIDADES COMPLEMENTARIAS Parte Uno:
1. De acuerdo con el concepto de abstracción mire su casa o apartamento y diga cual es la función de cada una de las partes.
2. Cual es la función de los descriptores private, public y protected.
3. Realiza un mapa conceptual con 15 términos del tema de modularidad. 4. Cual es la función principal de la jerarquía en la POO.
5. ¿Cual es la relación que existe entre jerarquía y polimorfismo? 6. Mediante un ejemplo explique el concepto de herencia
7. Realiza un árbol teniendo en cuanta las clases y subclases y lo que heredan de cada uno de las clases padres.
Parte Dos:
Realizar los ejercicos complementarios de Laboratorios de la Guia de Laboratotios y Consultar Bibliografia de Libros Virtual de la Unad y otros Autores 1. Autor: Deitel y Deitel Introducción DOO con UML y los Patrones de Diseño JDBC tm, SERVLETS, JSP tm Editorial Pearson Prentice Hall Quinta Edición, 2. David Arnow Gerald Weiss Introducción a la Programación con Java tm Actualización a la Versión 2 de Java Editorial Addison Wesley 3. Fcd Javier Ceballos Java 2 Curso de Programación 2 Edición Editorial Alfaomega Ra-Ma 4. Agustin Froute Java 2 Manual Usuario tutorial 3 Edición Editorial Alfaomega Ra-Ma 5. Herbert shildt Fundamentos de Programación Java 2 Editorial Mc Graw Hill . para conocer el lenguaje de programación JAVA ya que están resueltos solo los puede digitar compilar y ejecutar en la casa o laboratorio de su correspondiente CEAD o CERES.
UNIDAD 2. ESTRUCTURA DE UN OBJETO - INTRODUCCION A JAVA
Lección 16
Capitulo 4. Análisis De La Estructura Y Comportamiento De Un Objeto 4.1 Análisis de la Estructura de Objetos. 1
El análisis de la estructura de objetos (AEO) define las categorías de los objetos que percibimos y las formas en que los asociamos.
4.1.1 Objetos y Tipos de Objetos.
En el análisis se trata de identificar los tipos de objeto más que los objetos individuales en un sistema. Los tipos de objetos se definen en base a la comprensión del analista de nuestro mundo. Un objeto puede categorizarse de variadas formas.
4.1.2 Asociaciones de Objetos.
Es importante modelar la forma como los objetos se asocian entre sí. Además es necesario identificar el significado de la asociación y la cantidad de objetos con los que un objeto dado puede y debe asociarse (cardinalidad).
Representación para la Asociación entre dos Tipos de Objetos. Un objeto del tipo persona posee cero o muchos objetos del tipo vehículo. Un objeto del tipo vehículo es de un y sólo un objeto del tipo persona.
4.1.3 Jerarquías de Generalización.
Una de las vías de sentido común por las que el hombre organiza su volumen de conocimiento es el de las jerarquías, de lo más general a lo más específico.
Representación de una Jerarquía de generalización, para el tipo de objeto Persona. En las jerarquías se habla de subtipo o especialización de un supertipo o generalización. En el caso anterior, persona es el supertipo para Empleado y Estudiante, que son sus subtipos. Por otra parte, Empleado es el supertipo para los subtipos Ejecutivo y Vendedor. Los subtipos (niveles inferiores de la jerarquía) heredan las características de sus supertipos, además, cada instancia de un tipo de objeto lo es también de sus supertipos.
4.1.4 Jerarquías Compuestas.
Un objeto se denomina complejo si está formado por otros. Las jerarquías Compuestas permiten realizar agregaciones de objetos.
Un objeto del tipo edificio se compone de a lo menos un objeto del tipo piso. A su vez un objeto del tipo piso se compone de a lo menos un objeto del tipo pasillo, podría tener varios (o ninguno) objetos del tipo baño y oficina.
4.1.5 Diagramas de relación entre los objetos.
Los tipos de objetos están relacionados con otros tipos de objeto. Por ejemplo, un empleado trabaja en una sucursal, o un cliente realiza un pedido de varios productos.
Un objeto del tipo cliente puede ordenar muchos objetos del tipo pedidos, y un objeto del tipo pedido es ordenado por un y sólo un objeto del tipo cliente. Un objeto del tipo producto está en muchos o ningún objeto del tipo pedido, mientras que un objeto del tipo pedido tiene al menos un objeto del tipo producto.
4.1.6 Esquemas de Objetos.
La comprensión de un modelo suele ser más sencilla si los tipos de objetos y relaciones se presentan mediante un diagrama de relación entre objetos; los supertipos y subtipos se presentan en un diagrama de jerarquías de generalización y las estructuras compuestas en un diagrama compuesto. Sin embargo, para los usuarios más sofisticados puede ser útil presentarlo todo en un mismo diagrama, el que se denomina esquema de objetos.
Lección 17
4.2 Análisis del comportamiento de objetos 2
En el análisis del comportamiento de objetos (ACO) realizamos esquemas de eventos que muestran eventos, la secuencia en que ocurren y cómo los eventos cambian el estado de los objetos.
4.2.1 Estados de un Objeto.
Un objeto puede existir en varios estados. Por ejemplo, un objeto reservación aérea puede ser una instancia de alguno de los siguientes tipos de objeto:
Reservación solicitada,
Reservación en lista de espera, Reservación confirmada,
Reservación cancelada, Reservación satisfecha, Reservación archivada.
Tales tipos de objetos suelen percibirse como estados posibles del ciclo vital de un objeto. Sin embargo, un objeto puede tener una gran variedad de perspectivas de ciclos vitales. Por ejemplo, el mismo objeto reservación aérea también puede tener los siguientes estados relacionados con el pago:
Reservación no liquidada,
Reservación con un pago de depósito,
Reservación reembolsada.
Así, el estado de un objeto es la colección de asociaciones que tiene un objeto.
4.2.2 Eventos.
El mundo está lleno de eventos: una coneja tiene conejitos, llega el pesado del vecino en forma inesperada, un cliente solicita un préstamo, el servidor se cae, se termina la tarea, etc.
En el análisis orientado a objetos el mundo se describe en términos de los objetos y sus estados, así como los eventos que modifican esos estados.
Un evento produce un cambio en el estado de un objeto. Los eventos sirven como indicadores de los instantes en que ocurren los cambios de estado.
Para saber de los cambios y reaccionar adecuadamente ante ellos, debemos entender y modelar los eventos.
4.2.3 Tipos de Eventos
El analista no necesita conocer cada evento que ocurra en una organización: sólo los tipos de eventos.
Por ejemplo, el tipo de evento reservación en lista de espera confirmada es la colección de eventos donde un objeto cambia de una reservación en lista de espera a una reservación confirmada.
Los tipos de eventos indican los cambios sencillos en el estado de un objeto; por ejemplo, cuando se deposita dinero en una cuenta bancaria o se actualiza el sueldo de un trabajador. Básicamente, los tipos de eventos describen las siguientes formas de cambios de estado:
Un objeto se crea.
Un objeto se termina.
Un objeto se clasifica como una instancia de un tipo de objeto.
Un objeto se desclasifica como una instancia de un tipo de objeto. Un objeto cambia de clasificación.
Un atributo de un objeto se cambia.
Los objetos pueden asociar un objeto con otro. Por ejemplo, en la mayoría de las organizaciones, cuando un objeto se clasifica como empleado, debe estar asociado con un departamento. Un evento clasificará al objeto como empleado.
Otro evento creará una asociación entre el objeto empleado y un objeto Departamento (las asociaciones son objetos como los demás).
Algunos eventos requieren que antes ocurran otros. Por ejemplo, antes de cerrar un departamento, todos los empleados deben ser asignados a otra parte, las oficinas que ocupaban deben tener otro uso, etc.
Algunas veces, un evento puede provocar la reacción encadena de otros eventos. Por ejemplo, el cambio de circuito a las conexiones de un avión, puede exigir cambios a varios otros objetos.
Una operación hace que los eventos ocurran. Dibujamos la operación como un cuadro con esquinas redondeadas, puesto que los eventos indican los puntos en el tiempo en que se da el cambio de estado de un objeto. Los tipos de eventos se representan como triángulos negros llenos, generalmente unidos a la caja de operación.
Según el área que se modele, puede ocurrir más de un evento al terminar una operación, y cada uno de estos puede activar operaciones independientes.
4.2.4 El Ciclo Vital de un Objeto
La mayoría de los objetos tienen un ciclo vital en el que una sucesión de eventos pueden ocurrirle y cada uno de éstos modifica su estado.
En este análisis, se dibuja un diagrama que muestre el ciclo vital de un objeto, incluyendo los estados posibles de los objetos, además de los cambios de estado permisibles. Este se denomina diagrama de reja.
Diagrama de reja que muestra los estados posibles de un objeto reservación aérea. Las líneas horizontales representan estados y las verticales muestran las transiciones entre estados.
4.2.5 Interacciones entre tipos de objetos
La mayoría de los procesos requieren la interacción de varios objetos.
En esta otra figura, se desarrolla el diagrama anterior para mostrar las operaciones necesarias.
