Porgramacion Orientada a Objetos

1. IAGP 1 Programación Orientada a Objetos Desarrollo de software orientado a objetos Definición Método de desarrollo de software que basa la arquitectura del sistema en módulos deducidos de los tipos de objetos que se manipulan, en lugar de basarse en la función o funciones a las que el sistema está destinado a asegurar. No preguntes primero qué hace el sistema, pregunta ¡¡A QUIÉN LO HACE!!

2. IAGP 2 Programación Orientada a Objetos 2.1 Orígenes El tiempo transcurrido entre el desarrollo convencional del software y el desarrollo orientado a objetos, no se solapa. Hay más de 25 años, surgió con el lenguaje Simula, en Noruega, aunque comercialmente se ha difundido recientemente. Simula es acrónimo de “simulación lenguaje” y fue creado para soportar simulaciones, por O. J. Dahl yKristen Nygaard. Su propósito fue la simulación de sistemas físicos complejos con muchos cientos de componentes. En Simula los módulos no se basan en procedimientos como en la programación convencional, sino en los objetos físicos que se modelan en la simulación.

3. IAGP 3 Programación Orientada a Objetos Los objetos del mundo real pueden exhibir una variedad infinita de efectos sobre otros, creando, destruyendo, levantando, uniendo, comprando, doblándose, enviando, etc. Esta gran variedad suscita un problema: ¿Cómo se pueden representar en software las diversas clases de interacciones ? Los autores de Simula lograron una solución elegante a este problema: el mensaje. Los objetos interaccionan el uno con el otro con mensajes que piden que los objetos realicen sus métodos. Un mensaje es simplemente el nombre de un objeto seguido por el nombre de un método que el objeto sabe ejecutar. Si un método requiere alguna información adicional para saber qué hacer, el mensaje incluye la información como parámetros.

4. IAGP 4 Programación Orientada a Objetos El objeto que inicia un mensaje se llama el remitente de ese mensaje, y el objeto que recibe el mensaje se llama el receptor. El hecho de que los métodos están asociados siempre a objetos específicos tiene un efecto secundario interesante que resulta ser ventajoso. Diversos objetos pueden responder al mismo mensaje genérico, pero cada objeto puede interpretar el mensaje de una manera distinta. Por ejemplo, un objeto camión podría poner en ejecución su propia versión del mensaje mueve_A, al igual que una nave, un tren, un avión, una persona, o cualquier cosa que se mueva. En el mundo real la manera en que estos objetos determinan sus rutas, planean sus movimientos, y realizan estos desplazamientos se diferencia radicalmente, pero todos entenderían una petición común de ir a un destino especificado.

5. IAGP 5 Programación Orientada a Objetos La capacidad de diversos objetos para responder al mismo mensaje de diversas maneras se llama polimorfismo, que en griego significa "muchas formas." El término puede intimidar, y el polimorfismo a menudo se considera un concepto avanzado en tecnología de objetos. Pero la idea básica no podía ser más simple: cada objeto puede tener una respuesta única al mismo mensaje. A veces, una simulación implica solamente un ejemplo de una clase particular de objeto. Sin embargo es mucho más común, necesitar más de un objeto de cada tipo. Esta posibilidad levanta otra preocupación: sería extremadamente ineficaz redefinir los mismos métodos en cada ocurrencia de ese objeto.

6. IAGP 6 Programación Orientada a Objetos Aquí, otra vez, los autores de Simula aportaron una solución elegante: la clase. Una clase es una plantilla de software que define los métodos y las variables que se incluirán en un tipo particular de objeto. Los métodos y las variables que hacen el objeto se definen solamente una vez, en la definición de la clase. Los objetos que pertenecen a una clase se llaman generalmente instancias de la clase y contienen solamente sus propios valores particulares para las variables. Un programa orientado a objetos (poo), se define de la forma: Objetos + Mensajes = Programa

7. IAGP 7 Programación Orientada a Objetos

9. En otro nivel más profundo, es más natural porque refleja técnicas propias de la naturaleza para manejar complejidad. Es interesante fijarse en la estructura de organismos vivos para establecer un marco para entender la naturaleza adaptativa de los objetos.

10. IAGP 9 Programación Orientada a Objetos Programa OO Colección estructurada de clases Clase Implementación de un TAD Objeto Una instancia de una clase Los objetos se comunican mediante mensajes

11. IAGP 10 Programación Orientada a Objetos 2.2 Comparación con los seres vivos El bloque de edificio básico a partir del cual se componen los seres vivos es la célula. Las células son "paquetes orgánicos", como objetos, combinan la información relacionada y comportamiento. La mayoría de la información está contenida en moléculas de proteína, dentro del núcleo de la célula. El comportamiento, que puede extenderse desde conversión de energía al movimiento, es realizado por estructuras fuera del núcleo. Las células están rodeadas por una membrana que permite solamente ciertas clases de intercambios químicos con otras. Esta membrana protege el funcionamiento interno de la célula contra la intrusión exterior, y también oculta la complejidad, presentando un interfaz relativamente simple al resto del organismo.

12. IAGP 11 Programación Orientada a Objetos Todas las interacciones entre las células ocurren a través de los mensajes químicos, reconocidos por la membrana de la célula y pasados a su través al interior de la célula.

13. IAGP 12 Programación Orientada a Objetos Los objetos que contienen a otros, se llaman objetos compuestos, son importantes porque pueden representar estructuras más sofisticadas que los objetos simples. Un avión consiste en alas, motores, y otros componentes que son demasiado complejos para representarlos de forma simple. Colecciones de objetos Hay una clase especial de clases, a menudo llamada la colección de clases, que se puede encontrar en la biblioteca de clases en la mayoría de los lenguajes comerciales. Como el nombre sugiere, la función básica de una colección es recolectar juntos los objetos que se deben manejar como grupo.

14. IAGP 13 Programación Orientada a Objetos En un avión, por ejemplo, no crearíamos una variable separada para cada objeto del asiento, agruparíamos todos los objetos del asiento en una colección y pondríamos una referencia a esa colección en un solo conjunto llamado variable.

15. IAGP 14 Programación Orientada a Objetos Aunque los mecanismos reales de células y de objetos apenas podrían ser más diferentes, sus funciones son similares. Las células y los objetos encapsulan datos y comportamientos asociados; ambos tienen interfaces que definen qué señales responderán a su ambiente; ambos utilizan la comunicación basada en mensajes para ocultar complejidad; ambos se pueden organizar en una jerarquía de tipos especializados; y ambos proporcionan los bloques de edificio fundamentales para construir una variedad infinita de sistemas complejos. Esta semejanza, considerando la gran variedad de organismos vivos, demuestra claramente la flexibilidad de este acercamiento básico a a la construcción de sistemas complejos.

17. Un método que el receptor sabe ejecutar

19. IAGP 17 Programación Orientada a Objetos La potencia de los polimorfismos, simplificación de programas Supónganos que estamos desarrollando un sistema que incluya instrumentos financieros tales como bonos y acciones. El sistema debe permitir que realicemos una variedad de operaciones tales como añadir una nueva acción, seguir el funcionamiento de varias clases de instrumentos, y supervisión del valor actual de la cartera en su totalidad. Nuestra primera clase es cartera, un objeto compuesto que contiene un objeto de la colección de objetos llamada instrumentos_financieros. Nuestro primer método es agregar, que toma un objeto instrumento financiero como su parámetro.

20. IAGP 18 Programación Orientada a Objetos

22. Módulo: unidad básica de descomposición de un sistema software

24. Permitir una composición modular

25. Producir módulos fáciles de comprender

26. Favorecer la continuidad del software

29. Independiente de la descomposición modular

30. Ejemplos: Librerías de rutinas, Filtros de Unix

35. Ejemplo: Módulos de entrada de datos comprueben su validez.

37. Pocas conexiones entre módulos

38. Intercambio de información intermodular mínimo

39. Conexiones explícitas

40. Ocultamiento de InformaciónLas cuatro últimas se refieren a la comunicación entre módulos: uso o compartición de datos

42. Mantenimiento barato

43. Proceso de modelado más simple

44. Diseños más claros y manejables

45. Incremento productividad de programadores

46. Inconveniente: Curva de aprendizaje

47. Diseño con objetos  diseño procedural

49. Lenguajes O.O.: Representa elementos del marco del problema a resolver

50. Código (solución): descripción del problema

52. Programa: Conjunto de objetos. Se envían mensajes para decirse qué deben hacer

53. Objetos pueden estar compuestos por otros

54. Cada objeto es de un tipo (instancia de clase)

56. Objeto: Pertenece a una clase.

57. Define sus características y comportamiento

58. POO crea nuevos tipos e instancia los objetos necesarios de esos tipos

59. modelado: Mapeo 1 a 1 Problema  Solución

61. Crear clases

62. Crear clientes de esas clases

63. Sólo muestra lo necesario para quien programa clientes. Oculta el resto

64. Interface  ¿Qué solicitudes puedo hacer?

65. Implementación: Realización de las tareas de la interface

67. Abstracciones matemáticas:

68. No se menciona cómo se implementan las operaciones

69. Java permite la construcción de TAD's

71. El programa que usa el TAD no se modifica

72. Sólo cambian los métodos del TAD

73. Cambios transparentes al resto del programa

74. Operaciones soportadas por el TAD:

75. Decisión de diseño (Programador del TAD)

77. El cliente no necesita ver lo que no le afecta (simplicidad)

78. Modificaciones en la implementación sin afectar a la interface  Cliente no afectado

79. Niveles de acceso a miembros:

82. Composición: Relación "tiene un" (has-a)

83. Clases que contienen objetos de otras clases (member object)

84. Objetos miembro: Privados si no son necesarios en la interface

85. Herencia: Relación "es un" (is-a)

87. El nuevo tipo es un duplicado del otro con añadidos y/o modificaciones

88. Modificaciones en la clase original afectan a la clase hija

89. Herencia: ¿Es realmente necesaria?

91. Los miembros privados son inaccesibles

92. Duplica el interface de la original. Es del mismo tipo que la clase base

93. Formas de modificar la nueva clase:

94. Añadir nuevos métodos

96. Permite código independiente del tipo.

97. Fácil de escribir y entender

98. Al añadir nuevos tipos:

99. No hay que reescribir código

101. Mensaje a un objeto de tipo desconocido.

102. Se ejecuta el método correcto

103. No hay que especificarlo (en C++ virtual)

104. Upcasting (Conversión a superclase)

105. Ej. Figuras geométricas

106. Enlace dinámico.

108. Sólo se permiten objetos de subclases

109. Métodos abstractos (sin implementación)

110. Sólo en clases abstractas

111. Interfaces:

112. Impiden implementar cualquier función

113. Sólo declaraciones

114. Herencia diferente a clases (herencia múltiple)

116. Variables de instancia, globales a la clase.

117. Atributos de clase (información estática, compartida)

118. Constructores. Código de inicialización

120. Java invoca al constructor al crear el objeto

121. La instanciación (new) reserva el lugar de almacenamiento e invoca al constructor

122. Nombre del constructor = nombre de la clase

124. Una clase puede tener múltiples constructores

125. Sobrecarga de constructorespublic class Coordenada { double x, y; public Coordenada(){ x = 0.0; y = 0.0; } public Coordenada (double v1, double v2){ x = v1; y = v2; } }

127. Clase sin constructor: El compilador crea un constructor "por defecto".

128. Si hay constructores con argumentos, no se crea el "constructor por defecto". Ejemplo.

129. Error si se invoca el constr. sin parámetros

130. Constructores que invocan a otros constructores:

132. Permite invocar métodos del objeto actual.

133. No es necesario this para hacer eso

134. Permite referenciar atributos del objeto actual

135. Necesario si estan ocultos por parámetros / variables de ámbito más local. Ejemplo.

136. Permite devolver una ref. al objeto actual

138. Reutilización de código por medio de herencia

139. super invoca al comportamiento anterior.

140. Además se puede añadir comportamiento adicional

141. Implícita en constructores como 1ª instrucción

143. Desde métodos static la referencia this no tiene sentido

144. No se puede acceder a miembros no estáticos desde métodos estáticos

145. static: Semántica de "ámbito global"

147. Creado por Alan Kay, Adele Goldberg y Daniel Ingalls

148. Influenciado por Simula y Lisp

149. “El objetivo del proyecto de Smalltalk es proporcionar soporte informatizado para el espíritu creativo”

151. “Un lenguaje para ordenadores debería:

152. soportar el concepto de Objeto y proporcionar un medio uniforme para identificarlos.

153. proporcionar un medio de clasificar los objetos y de crear nuevas clases con la misma base que las del núcleo.

154. ser Independiente de la representación (polimorfismo)

155. factorizar comportamiento común (herencia)”

157. A finales de 1993 se creó el Comité para la estandarización de Smalltalk X3J20.

158. El primer borrador aparece a finales de 1995

159. 50% sintaxis/semántica y 50% Librerías de clases

160. Fácil debido a la simplicidad del lenguaje

161. Código de aplicaciones muy portable

162. En 1995 se forma el STIC (SmallTalk Industry Council) “una voz unificada para la comunidad Smalltalk”

164. Responder a las necesidades de la industria Smalltalk

165. Favorecer la aparición de estándares

166. Crear un “punto de encuentro” para la comunidad Smalltalkhttp://www.stic.org Apuntes sobre Smalltalk: http://www.um.es/informatica/alumnos/apuntes/tercero/poo/smalltalk.ppt

169. Pero tiene características especiales (diagonal) y propiedades especiales (4 lados, ángulos rectos)

170. Algunas características de polígono pueden implementarse más eficientementeclass Rectangulo inherit Poligono feature ...Características específicas para rectángulos end