IAGP <br />1<br />Programación Orientada a Objetos<br />Desarrollo de software orientado a objetos<br />Definición<br />Mé...
IAGP <br />2<br />Programación Orientada a Objetos<br />2.1 Orígenes<br />El tiempo transcurrido entre el desarrollo conve...
IAGP <br />3<br />Programación Orientada a Objetos<br />Los objetos del mundo real pueden exhibir una variedad infinita de...
IAGP <br />4<br />Programación Orientada a Objetos<br />El objeto que inicia un mensaje se llama el remitente de ese mensa...
IAGP <br />5<br />Programación Orientada a Objetos<br />La capacidad de diversos objetos para responder al mismo mensaje d...
IAGP <br />6<br />Programación Orientada a Objetos<br />Aquí, otra vez, los autores de Simula aportaron una solución elega...
IAGP <br />7<br />Programación Orientada a Objetos<br />
IAGP <br />8<br />Programación Orientada a Objetos<br />La programación orientada a objetos, se dice a menudo que es más n...
 En otro nivel más profundo, es más natural porque refleja técnicas propias de la naturaleza para manejar complejidad.  </...
IAGP <br />9<br />Programación Orientada a Objetos<br />Programa OO<br />Colección estructurada<br />de clases<br />Clase<...
IAGP <br />10<br />Programación Orientada a Objetos<br />2.2 Comparación con los seres vivos<br />El bloque de edificio bá...
IAGP <br />11<br />Programación Orientada a Objetos<br />Todas las interacciones entre las células ocurren a través de los...
IAGP <br />12<br />Programación Orientada a Objetos<br />Los objetos que contienen a otros, se llaman objetos compuestos, ...
IAGP <br />13<br />Programación Orientada a Objetos<br />En un avión, por ejemplo, no crearíamos una variable separada par...
IAGP <br />14<br />Programación Orientada a Objetos<br />Aunque los mecanismos reales de células y de objetos apenas podrí...
IAGP <br />15<br />Programación Orientada a Objetos<br />¡La naturaleza, después de todo, ha estado utilizando el acercami...
 Un método que el receptor sabe ejecutar
 Un conjunto de parámetros que el método requiere para realizar su función</li></li></ul><li>IAGP <br />16<br />Programaci...
IAGP <br />17<br />Programación Orientada a Objetos<br />La potencia de los polimorfismos, simplificación de programas<br ...
IAGP <br />18<br />Programación Orientada a Objetos<br />
IAGP <br />19<br />Programación Orientada a Objetos<br />2.3 Modularidad<br />Modularidad<br /><ul><li> Extensibilidad + R...
 Módulo: unidad básica de descomposición de un sistema software
 Un método de construcción de software es modular si ayuda a producir sistemas software a partir de elementos autónomos in...
 Permitir una composición modular
 Producir módulos fáciles de comprender
 Favorecer la continuidad del software
 Protección modular</li></li></ul><li>IAGP <br />21<br />Programación Orientada a Objetos<br />Descomposición modular<br /...
Contra-ejemplo: Módulos de Inicialización</li></li></ul><li>IAGP <br />22<br />Programación Orientada a Objetos<br />Compo...
 Independiente de la descomposición modular
 Ejemplos: Librerías de rutinas, Filtros de Unix
 Contra-ejemplo: Preprocesadores de lenguajes</li></li></ul><li>IAGP <br />23<br />Programación Orientada a Objetos<br />C...
 Contra-ejemplo: Dependencias secuenciales</li></li></ul><li>IAGP <br />24<br />Programación Orientada a Objetos<br />Cont...
 Ejemplos:</li></ul>Constantes simbólicas y Principio de Acceso Uniforme<br /><ul><li> Contra- ejemplos:</li></ul>Diseño d...
IAGP <br />25<br />Programación Orientada a Objetos<br />Protección Modular<br />Un método satisface la Continuidad Modula...
 Ejemplo: Módulos de entrada de datos comprueben su validez.
 Contra-ejemplo: Excepciones no disciplinadas.</li></li></ul><li>IAGP <br />26<br />Programación Orientada a Objetos<br />...
 Pocas conexiones entre módulos
 Intercambio de información intermodular mínimo
 Conexiones explícitas
 Ocultamiento de Información</li></ul>Las cuatro últimas se refieren a la comunicación entre módulos: uso o compartición d...
IAGP <br />27<br />Programación Orientada a Objetos<br />2.4 Otras consideraciones<br />Impacto de la POO<br /><ul><li> De...
 Mantenimiento barato
 Proceso de modelado más simple
 Diseños más claros y manejables
 Incremento productividad de programadores
 Inconveniente: Curva de aprendizaje
Diseño con objetos  diseño procedural
 Librerías bien diseñadas y fáciles de usar</li></li></ul><li>IAGP <br />28<br />Programación Orientada a Objetos<br />Abs...
 Lenguajes O.O.:  Representa elementos del marco del problema a resolver
 Código (solución): descripción del problema
 Objetos: Tienen su estado y pueden realizar operaciones</li></li></ul><li>IAGP <br />29<br />Programación Orientada a Obj...
 Programa: Conjunto de objetos. Se envían mensajes para decirse qué deben hacer
 Objetos pueden estar compuestos por otros
 Cada objeto es de un tipo (instancia de clase)
Upcoming SlideShare
Loading in …5
×

Programacion o o

717 views

Published on

Porgramacion Orientada a Objetos

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
717
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Programacion o o

  1. 1. IAGP <br />1<br />Programación Orientada a Objetos<br />Desarrollo de software orientado a objetos<br />Definición<br />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.<br />No preguntes primero qué hace el sistema, pregunta ¡¡A QUIÉN LO HACE!!<br />
  2. 2. IAGP <br />2<br />Programación Orientada a Objetos<br />2.1 Orígenes<br />El tiempo transcurrido entre el desarrollo convencional del software y el desarrollo orientado a objetos, no se solapa.<br />Hay más de 25 años, surgió con el lenguaje Simula, en Noruega, aunque comercialmente se ha difundido recientemente.<br />Simula es acrónimo de “simulación lenguaje” y fue creado para soportar simulaciones, por O. J. Dahl yKristen Nygaard.<br />Su propósito fue la simulación de sistemas físicos complejos con muchos cientos de componentes.<br />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.<br />
  3. 3. IAGP <br />3<br />Programación Orientada a Objetos<br />Los objetos del mundo real pueden exhibir una variedad infinita de efectos sobre otros, creando, destruyendo, levantando, uniendo, comprando, doblándose, enviando, etc. <br />Esta gran variedad suscita un problema: ¿Cómo se pueden representar en software las diversas clases de interacciones ? <br />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. <br />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. <br />
  4. 4. IAGP <br />4<br />Programación Orientada a Objetos<br />El objeto que inicia un mensaje se llama el remitente de ese mensaje, y el objeto que recibe el mensaje se llama el receptor. <br />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. <br />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. <br />
  5. 5. IAGP <br />5<br />Programación Orientada a Objetos<br />La capacidad de diversos objetos para responder al mismo mensaje de diversas maneras se llama polimorfismo, que en griego significa "muchas formas." <br />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. <br />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. <br />
  6. 6. IAGP <br />6<br />Programación Orientada a Objetos<br />Aquí, otra vez, los autores de Simula aportaron una solución elegante: la clase. <br />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.<br />Los objetos que pertenecen a una clase se llaman generalmente instancias de la clase y contienen solamente sus propios valores particulares para las variables. <br />Un programa orientado a objetos (poo), se define de la forma:<br />Objetos + Mensajes = Programa<br />
  7. 7. IAGP <br />7<br />Programación Orientada a Objetos<br />
  8. 8. IAGP <br />8<br />Programación Orientada a Objetos<br />La programación orientada a objetos, se dice a menudo que es más natural que la programación tradicional, y es verdad en dos niveles. <br /><ul><li> En un nivel, la POO es más natural porque permite que organicemos la información de la forma que nos es familiar, según lo ilustrado en las jerarquías de las clases.
  9. 9. En otro nivel más profundo, es más natural porque refleja técnicas propias de la naturaleza para manejar complejidad. </li></ul>Es interesante fijarse en la estructura de organismos vivos para establecer un marco para entender la naturaleza adaptativa de los objetos.<br />
  10. 10. IAGP <br />9<br />Programación Orientada a Objetos<br />Programa OO<br />Colección estructurada<br />de clases<br />Clase<br />Implementación de un TAD<br />Objeto<br />Una instancia de una clase<br />Los objetos se comunican mediante mensajes<br />
  11. 11. IAGP <br />10<br />Programación Orientada a Objetos<br />2.2 Comparación con los seres vivos<br />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. <br />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. <br />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. <br />
  12. 12. IAGP <br />11<br />Programación Orientada a Objetos<br />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. <br />
  13. 13. IAGP <br />12<br />Programación Orientada a Objetos<br />Los objetos que contienen a otros, se llaman objetos compuestos, son importantes porque pueden representar estructuras más sofisticadas que los objetos simples.<br />Un avión consiste en alas, motores, y otros componentes que son demasiado complejos para representarlos de forma simple. <br />Colecciones de objetos<br />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. <br />
  14. 14. IAGP <br />13<br />Programación Orientada a Objetos<br />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. <br />
  15. 15. IAGP <br />14<br />Programación Orientada a Objetos<br />Aunque los mecanismos reales de células y de objetos apenas podrían ser más diferentes, sus funciones son similares. <br />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. <br />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. <br />
  16. 16. IAGP <br />15<br />Programación Orientada a Objetos<br />¡La naturaleza, después de todo, ha estado utilizando el acercamiento algunos miles de millones de años más que los diseñadores del software! <br />Anatomía de los componentes de un mensaje<br />Un mensaje consiste de tres partes: <br /><ul><li> Un objeto receptor
  17. 17. Un método que el receptor sabe ejecutar
  18. 18. Un conjunto de parámetros que el método requiere para realizar su función</li></li></ul><li>IAGP <br />16<br />Programación Orientada a Objetos<br />Respuestas a los mensajes<br />En la mayoría de los sistemas, los mensajes requieren una cierta clase de respuesta del receptor. Esta respuesta es generalmente llamada valor de retorno, puede ser datos simples, valores u objetos.<br />
  19. 19. IAGP <br />17<br />Programación Orientada a Objetos<br />La potencia de los polimorfismos, simplificación de programas<br />Supónganos que estamos desarrollando un sistema que incluya instrumentos financieros tales como bonos y acciones. <br />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. <br />Nuestra primera clase es cartera, un objeto compuesto que contiene un objeto de la colección de objetos llamada instrumentos_financieros.<br /> Nuestro primer método es agregar, que toma un objeto instrumento financiero como su parámetro. <br />
  20. 20. IAGP <br />18<br />Programación Orientada a Objetos<br />
  21. 21. IAGP <br />19<br />Programación Orientada a Objetos<br />2.3 Modularidad<br />Modularidad<br /><ul><li> Extensibilidad + Reutilizaciónnecesidad de </li></ul>arquitecturas flexibles hechas con componentes autónomos<br /><ul><li> Programa modular: formado por un conjunto de módulos
  22. 22. Módulo: unidad básica de descomposición de un sistema software
  23. 23. Un método de construcción de software es modular si ayuda a producir sistemas software a partir de elementos autónomos interconectados por una estructura simple y coherente.</li></li></ul><li>IAGP <br />20<br />Programación Orientada a Objetos<br />Modularidad: 5 criterios<br />Cinco criterios, cinco reglas, cinco principios.<br />Requisitos que debe satisfacer un método de construcción de software para merecer el nombre de modular:<br /><ul><li> Permitir una descomposición modular
  24. 24. Permitir una composición modular
  25. 25. Producir módulos fáciles de comprender
  26. 26. Favorecer la continuidad del software
  27. 27. Protección modular</li></li></ul><li>IAGP <br />21<br />Programación Orientada a Objetos<br />Descomposición modular<br />Un método de construcción de software satisface la descomposición modular si permite la descomposición de un problema en un pequeño número de subproblemas menos complejos, conectados por una estructura simple, y que se pueden abordar por separado.<br />Importante que las dependencias sean mínimas y que se conozcan. <br /><ul><li>Ejemplo: Diseño Descendente
  28. 28. Contra-ejemplo: Módulos de Inicialización</li></li></ul><li>IAGP <br />22<br />Programación Orientada a Objetos<br />Composición modular<br />Un método satisface la composición modular si favorece la producción de elementos software que pueden ser combinados para crear nuevos sistemas, posiblemente en un entorno diferente a aquel en el que se idearon.<br /><ul><li> Relacionada con el objetivo de reutilización
  29. 29. Independiente de la descomposición modular
  30. 30. Ejemplos: Librerías de rutinas, Filtros de Unix
  31. 31. Contra-ejemplo: Preprocesadores de lenguajes</li></li></ul><li>IAGP <br />23<br />Programación Orientada a Objetos<br />Comprensión Modular<br />Se satisface si facilita que quién lea un módulo pueda comprenderlo sin necesidad de acudir a otros módulos (en el peor de los casos a unos pocos módulos).<br /><ul><li> Relacionado con el mantenimiento
  32. 32. Contra-ejemplo: Dependencias secuenciales</li></li></ul><li>IAGP <br />24<br />Programación Orientada a Objetos<br />Continuidad Modular<br />Un método satisface la Continuidad Modular si se favorecen arquitecturas software en las que un cambio pequeño en la especificación origina un cambio en un solo módulo, o en un pequeño número de módulos.<br /><ul><li> Relacionado con la extensibilidad
  33. 33. Ejemplos:</li></ul>Constantes simbólicas y Principio de Acceso Uniforme<br /><ul><li> Contra- ejemplos:</li></ul>Diseño de programas basado en la representación física de los datos y el uso de vectores estáticos<br />
  34. 34. IAGP <br />25<br />Programación Orientada a Objetos<br />Protección Modular<br />Un método satisface la Continuidad Modular si se originan arquitecturas en las que el efecto de una condición excepcional acaecida en tiempo de ejecución sólo afecta al módulo dónde se produce, o sólo se propaga a los módulos vecinos.<br /><ul><li> Relacionado con la robustez
  35. 35. Ejemplo: Módulos de entrada de datos comprueben su validez.
  36. 36. Contra-ejemplo: Excepciones no disciplinadas.</li></li></ul><li>IAGP <br />26<br />Programación Orientada a Objetos<br />Modularidad: 5 reglas<br />De los criterios anteriores se derivan cinco reglas que se deben seguir para asegurar la modularidad<br /><ul><li> Correspondencia directa
  37. 37. Pocas conexiones entre módulos
  38. 38. Intercambio de información intermodular mínimo
  39. 39. Conexiones explícitas
  40. 40. Ocultamiento de Información</li></ul>Las cuatro últimas se refieren a la comunicación entre módulos: uso o compartición de datos<br />
  41. 41. IAGP <br />27<br />Programación Orientada a Objetos<br />2.4 Otras consideraciones<br />Impacto de la POO<br /><ul><li> Desarrollo más rápido.
  42. 42. Mantenimiento barato
  43. 43. Proceso de modelado más simple
  44. 44. Diseños más claros y manejables
  45. 45. Incremento productividad de programadores
  46. 46. Inconveniente: Curva de aprendizaje
  47. 47. Diseño con objetos  diseño procedural
  48. 48. Librerías bien diseñadas y fáciles de usar</li></li></ul><li>IAGP <br />28<br />Programación Orientada a Objetos<br />Abstracción y modelado<br /><ul><li> Modelado del problema: Proceso de abstracción
  49. 49. Lenguajes O.O.: Representa elementos del marco del problema a resolver
  50. 50. Código (solución): descripción del problema
  51. 51. Objetos: Tienen su estado y pueden realizar operaciones</li></li></ul><li>IAGP <br />29<br />Programación Orientada a Objetos<br />Características de la O.O.<br /><ul><li> Todo es un objeto (alumno, factura, polígono)
  52. 52. Programa: Conjunto de objetos. Se envían mensajes para decirse qué deben hacer
  53. 53. Objetos pueden estar compuestos por otros
  54. 54. Cada objeto es de un tipo (instancia de clase)
  55. 55. Objetos de un mismo tipo pueden recibir los mismos mensajes</li></li></ul><li>IAGP <br />30<br />Programación Orientada a Objetos<br />Interface de un objeto<br /><ul><li> Elementos del problema: Entidad (Objeto)
  56. 56. Objeto: Pertenece a una clase.
  57. 57. Define sus características y comportamiento
  58. 58. POO crea nuevos tipos e instancia los objetos necesarios de esos tipos
  59. 59. modelado: Mapeo 1 a 1 Problema  Solución
  60. 60. Tipo: Interface. Informa de las peticiones que se pueden hacer a objetos de ese tipo</li></li></ul><li>IAGP <br />31<br />Programación Orientada a Objetos<br />Encapsulación<br /><ul><li> Programador: Dos puntos de vista
  61. 61. Crear clases
  62. 62. Crear clientes de esas clases
  63. 63. Sólo muestra lo necesario para quien programa clientes. Oculta el resto
  64. 64. Interface  ¿Qué solicitudes puedo hacer?
  65. 65. Implementación: Realización de las tareas de la interface
  66. 66. Envío de mensajes (ejecución de un método)</li></li></ul><li>IAGP <br />32<br />Programación Orientada a Objetos<br />Tipos Abstractos de Datos<br /><ul><li> Conjunto de objetos que ofrecen una serie de operaciones
  67. 67. Abstracciones matemáticas:
  68. 68. No se menciona cómo se implementan las operaciones
  69. 69. Java permite la construcción de TAD's
  70. 70. Mecanismos para la ocultación de detalles de implementación</li></li></ul><li>IAGP <br />33<br />Programación Orientada a Objetos<br /><ul><li> Si se modifica la implementación:
  71. 71. El programa que usa el TAD no se modifica
  72. 72. Sólo cambian los métodos del TAD
  73. 73. Cambios transparentes al resto del programa
  74. 74. Operaciones soportadas por el TAD:
  75. 75. Decisión de diseño (Programador del TAD)
  76. 76. Ejemplos: Listas, conjuntos, grafos, ...</li></li></ul><li>IAGP <br />34<br />Programación Orientada a Objetos<br />Control de acceso<br /><ul><li> Disponibilidad de métodos. Razones:
  77. 77. El cliente no necesita ver lo que no le afecta (simplicidad)
  78. 78. Modificaciones en la implementación sin afectar a la interface  Cliente no afectado
  79. 79. Niveles de acceso a miembros:
  80. 80. public, private, protected: Quién puede hacer uso</li></li></ul><li>IAGP <br />35<br />Programación Orientada a Objetos<br />
  81. 81. IAGP <br />36<br />Programación Orientada a Objetos<br />Reutilización<br /><ul><li> Uso habitual: Instanciar un objeto de una clase
  82. 82. Composición: Relación "tiene un" (has-a)
  83. 83. Clases que contienen objetos de otras clases (member object)
  84. 84. Objetos miembro: Privados si no son necesarios en la interface
  85. 85. Herencia: Relación "es un" (is-a)
  86. 86. Modificación (especialización) de una clase ya existente</li></li></ul><li>IAGP <br />37<br />Programación Orientada a Objetos<br />Herencia<br /><ul><li> Evita crear tipos (clases) nuevos por necesidad de similar funcionalidad
  87. 87. El nuevo tipo es un duplicado del otro con añadidos y/o modificaciones
  88. 88. Modificaciones en la clase original afectan a la clase hija
  89. 89. Herencia: ¿Es realmente necesaria?
  90. 90. Composición mucho más habitual</li></li></ul><li>IAGP <br />38<br />Programación Orientada a Objetos<br />Herencia: Subclases<br /><ul><li> Nuevo tipo. Contiene todos los miembros del anterior
  91. 91. Los miembros privados son inaccesibles
  92. 92. Duplica el interface de la original. Es del mismo tipo que la clase base
  93. 93. Formas de modificar la nueva clase:
  94. 94. Añadir nuevos métodos
  95. 95. Cambiar el comportamiento de un método (override)</li></li></ul><li>IAGP <br />39<br />Programación Orientada a Objetos<br />Herencia: Polimorfismo<br /><ul><li> Objetos de clases derivadas se pueden tratar como de la clase base
  96. 96. Permite código independiente del tipo.
  97. 97. Fácil de escribir y entender
  98. 98. Al añadir nuevos tipos:
  99. 99. No hay que reescribir código
  100. 100. Programas extensibles</li></li></ul><li>IAGP <br />40<br />Programación Orientada a Objetos<br />Ejemplos:<br /><ul><li> Polimorfismo:
  101. 101. Mensaje a un objeto de tipo desconocido.
  102. 102. Se ejecuta el método correcto
  103. 103. No hay que especificarlo (en C++ virtual)
  104. 104. Upcasting (Conversión a superclase)
  105. 105. Ej. Figuras geométricas
  106. 106. Enlace dinámico.
  107. 107. Ej. Trabajadores y nóminas</li></li></ul><li>IAGP <br />41<br />Programación Orientada a Objetos<br />Clases abstractas<br /><ul><li> Subclases diferentes con un interface único
  108. 108. Sólo se permiten objetos de subclases
  109. 109. Métodos abstractos (sin implementación)
  110. 110. Sólo en clases abstractas
  111. 111. Interfaces:
  112. 112. Impiden implementar cualquier función
  113. 113. Sólo declaraciones
  114. 114. Herencia diferente a clases (herencia múltiple)
  115. 115. Las subclases "implementan" interfaces</li></li></ul><li>IAGP <br />42<br />Programación Orientada a Objetos<br />Declaración de clases<br /><acceso> class <nombre><br />{<br /> <miembros> // "members"<br />}<br />Miembros:<br /><ul><li> Atributos:
  116. 116. Variables de instancia, globales a la clase.
  117. 117. Atributos de clase (información estática, compartida)
  118. 118. Constructores. Código de inicialización
  119. 119. Métodos. Comportamiento.</li></li></ul><li>IAGP <br />43<br />Programación Orientada a Objetos<br />Constructores<br /><ul><li> Se garantiza la inicialización de cada objeto (sus atributos) con un constructor
  120. 120. Java invoca al constructor al crear el objeto
  121. 121. La instanciación (new) reserva el lugar de almacenamiento e invoca al constructor
  122. 122. Nombre del constructor = nombre de la clase
  123. 123. Se encargan de todas las operaciones de inicialización necesarias.</li></li></ul><li>IAGP <br />44<br />Programación Orientada a Objetos<br /><ul><li> Constructor: No tiene valor de retorno
  124. 124. Una clase puede tener múltiples constructores
  125. 125. Sobrecarga de constructores</li></ul>public class Coordenada<br />{<br /> double x, y;<br /> public Coordenada(){<br /> x = 0.0; y = 0.0;<br /> }<br /> public Coordenada (double v1, double v2){<br /> x = v1; y = v2;<br /> }<br />}<br />
  126. 126. IAGP <br />45<br />Programación Orientada a Objetos<br /><ul><li> Constructor "por defecto". Sin parámetros.
  127. 127. Clase sin constructor: El compilador crea un constructor "por defecto".
  128. 128. Si hay constructores con argumentos, no se crea el "constructor por defecto". Ejemplo.
  129. 129. Error si se invoca el constr. sin parámetros
  130. 130. Constructores que invocan a otros constructores:
  131. 131. llamada a this(...). Ejemplo.</li></li></ul><li>IAGP <br />46<br />Programación Orientada a Objetos<br />La referencia this<br /><ul><li> Referencia al objeto actual.
  132. 132. Permite invocar métodos del objeto actual.
  133. 133. No es necesario this para hacer eso
  134. 134. Permite referenciar atributos del objeto actual
  135. 135. Necesario si estan ocultos por parámetros / variables de ámbito más local. Ejemplo.
  136. 136. Permite devolver una ref. al objeto actual
  137. 137. Permite invocaciones entre constructores</li></li></ul><li>IAGP <br />47<br />Programación Orientada a Objetos<br />La llamada a super<br /><ul><li> Referencia a la superclase de la que desciende la clase actual
  138. 138. Reutilización de código por medio de herencia
  139. 139. super invoca al comportamiento anterior.
  140. 140. Además se puede añadir comportamiento adicional
  141. 141. Implícita en constructores como 1ª instrucción
  142. 142. en métodos: super.nombre_metodo()</li></li></ul><li>IAGP <br />48<br />Programación Orientada a Objetos<br />Miembros de tipo static<br /><ul><li> Miembros (métodos o atributos) implementados a nivel de clase
  143. 143. Desde métodos static la referencia this no tiene sentido
  144. 144. No se puede acceder a miembros no estáticos desde métodos estáticos
  145. 145. static: Semántica de "ámbito global"
  146. 146. Permite desarrollo de código sin usar POO</li></li></ul><li>IAGP <br />49<br />Programación Orientada a Objetos<br />2.5 Lenguaje Smalltalk<br /><ul><li> Surge en los años 1970, en el Centro de Investigación de Xerox en Palo Alto (PARC) en EE.UU.
  147. 147. Creado por Alan Kay, Adele Goldberg y Daniel Ingalls
  148. 148. Influenciado por Simula y Lisp
  149. 149. “El objetivo del proyecto de Smalltalk es proporcionar soporte informatizado para el espíritu creativo”
  150. 150. “Lenguaje de descripción (lenguaje de programación) que sirva como una interface entre los modelos mentales y los modelos en el ordenador, y además un lenguaje de interacción (interfaz de usuario) que traslade los sistemas de comunicación humana a los ordenadores”</li></li></ul><li>IAGP <br />50<br />Programación Orientada a Objetos<br /><ul><li> “El sistema debería construirse con el mínimo nº de partes fijas y todas las partes deberían encontrarse en un marco uniforme.”
  151. 151. “Un lenguaje para ordenadores debería:
  152. 152. soportar el concepto de Objeto y proporcionar un medio uniforme para identificarlos.
  153. 153. proporcionar un medio de clasificar los objetos y de crear nuevas clases con la misma base que las del núcleo.
  154. 154. ser Independiente de la representación (polimorfismo)
  155. 155. factorizar comportamiento común (herencia)”
  156. 156. “La ejecución debería verse como una capacidad intrínseca de los objetos que pueden ser invocados de manera uniforme mediante el envío de mensajes.”</li></li></ul><li>IAGP <br />51<br />Programación Orientada a Objetos<br /><ul><li> Para que un lenguaje de desarrollo llegue a ser ampliamente aceptado deber ser estandarizado.
  157. 157. A finales de 1993 se creó el Comité para la estandarización de Smalltalk X3J20.
  158. 158. El primer borrador aparece a finales de 1995
  159. 159. 50% sintaxis/semántica y 50% Librerías de clases
  160. 160. Fácil debido a la simplicidad del lenguaje
  161. 161. Código de aplicaciones muy portable
  162. 162. En 1995 se forma el STIC (SmallTalk Industry Council) </li></ul>“una voz unificada para la comunidad Smalltalk”<br />
  163. 163. IAGP <br />52<br />Programación Orientada a Objetos<br />Los objetivos del STIC son:<br /><ul><li> Lograr que Smalltalk sea el LOO elegido para el desarrollo de aplicaciones en la empresa
  164. 164. Responder a las necesidades de la industria Smalltalk
  165. 165. Favorecer la aparición de estándares
  166. 166. Crear un “punto de encuentro” para la comunidad Smalltalk</li></ul>http://www.stic.org<br />Apuntes sobre Smalltalk:<br />http://www.um.es/informatica/alumnos/apuntes/tercero/poo/smalltalk.ppt<br />
  167. 167. IAGP <br />53<br />Programación Orientada a Objetos<br />2.6 Ejemplo<br />Polígonos y Rectángulos<br /><ul><li> Tenemos la clase Poligono y necesitamos representar rectángulos.</li></ul>¿Debemos crear la clase Rectangulo partiendo de cero?<br />Podemos aprovechar la existencia de similitudes y particularidades entre ambas clases<br />
  168. 168. IAGP <br />54<br />Programación Orientada a Objetos<br /><ul><li> Un rectángulo tiene muchas de las características de un polígono (rotar, trasladar, vértices,..)
  169. 169. Pero tiene características especiales (diagonal) y propiedades especiales (4 lados, ángulos rectos)
  170. 170. Algunas características de polígono pueden implementarse más eficientemente</li></ul>class Rectangulo inherit<br /> Poligono<br />feature<br /> ...Características específicas para rectángulos<br />end<br />

×