Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Unidad_01_04.pdf

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Unidad_01_02.pdf
Unidad_01_02.pdf
Cargando en…3
×

Eche un vistazo a continuación

1 de 15 Anuncio

Más Contenido Relacionado

Más reciente (20)

Anuncio

Unidad_01_04.pdf

  1. 1. 01.04 HERENCIA Y POLIMORFISMO ING. MAURICIO ORTIZ MORTIZO@UPS.EDU.EC C-CT-ICO-102 | PROGRAMACIÓN ORIENTADA A OBJETOS UNIDAD 01.- PROGRAMACIÓN ORIENTADA A OBJETOS
  2. 2. LA NECESIDAD DE DISEÑAR DE SOFTWARE  Cada vez se tiende a crear software con mayores grados de complejidad.  Una manera de manejar la complejidad del software es mediante la construcción de modelos o representaciones, las mismas que son de gran ayuda para asegurarse de definir que se quiere programar.  Diseñar la solución antes de implementarla.  Los arquitectos antes de construir necesitan modelar o diseñar los planos para luego construir el edificio.  Primero se debe diseñar el software mediante los requerimientos que nos especifique el usuario, para luego implementar la solución mediante un lenguaje de programación.  El problema está en explicar la solución a grupos de 50 o 100 programadores para que la implementen en un lenguaje.
  3. 3. NO EXISTE LA BALA DE PLATA  Adaptación: El software lo que hace es automatizar procesos, por lo cual debe adaptarse al modelo actual de la empresa y no al revés  Complejidad: El software cada vez se vuelve más complejo y difícil de controlar por el crecimiento de los requerimientos y por la magnitud en sí del tamaño.  Cambio continuo: El software es fácilmente modicable, y por esta razón a pesar de llegar a ser un software exitoso se le aumentarán requerimientos.  Invisibilidad: El software es invisible, no se puede modelar mediante abstracciones geométricas o escalas.
  4. 4. NAVEGABILIDAD  Esta característica es opcional pero muy importante dentro de las relaciones, ya que permite indicar la dirección en la cual pasará el objeto de una clase a otra.  Cuando dos clases se encuentran relacionadas, y lo que se desea es representar que en la ClaseA se va a crear un objeto de la ClaseB, entonces la navegabilidad se representa con una flecha en la ClaseB.  En la relación se puede describir el nombre del objeto que se creará a partir de una ClaseB en la ClaseB.
  5. 5. VISIBILIDAD  public (+) Permite que el atributo o método sea accesible desde cualquier clase.  private (-) El atributo o método es solamente desde la clase donde se crea.  protected (#) El atributo o método desde la clase donde se crea, de las subclases mediante herencia y desde el paquete del que forma parte.  Sin ninguna palabra reservada significa que es accesible desde cualquier clase dentro del paquete.
  6. 6. GETTERS & SETTERS  Getters  Significa obtener  Sirve para acceder al valor asignado a un atributo.  Retorno el mismo tipo del atributo.  Setters  Significa establecer  Sirve para asignar un valor inicial a un atributo  El Setter NO retorna valores.  Solamente sirve para dar acceso público a los atributos.
  7. 7. HERENCIA I  Permite la creación de clases a partir de otras ya existentes.  Debe existir una clase padre (superclase) y clases hijas (clases derivadas)  Las clases derivadas heredan los métodos y atributos de la clase superclase.  Ejemplo:  Tenemos una superclase Persona y dos clases derivadas Empleado y Estudiante  Los empleados y los estudiantes tienen atributos o métodos comunes y para optimizar el diseño, se puede crear una superclase que contenga todo lo común.  Los atributos o métodos que no sean comunes se mantendrán en las respectivas clase derivadas.
  8. 8. HERENCIA II
  9. 9. CONSTRUCTORES  Métodos especiales que inicializan los objetos de una clase.  Los constructores son opcionales.  El constructor se ejecuta implícitamente cuando se crea una instancia.  El constructor debe llamarse igual que la clase.  No tiene parámetro de salida, por lo cual no debe llevar la palabra void.  Existe un constructor por defecto sin parámetros.
  10. 10. SOBRECARGA  Definir dos o más métodos o constructores con el mismo nombre, pero con diferente firma de parámetros.  Permite reducir el número de identificadores para la misma acción.
  11. 11. EJERCICIO EN CLASE
  12. 12. CLASES ABSTRACTAS I  Son clases especiales que no se pueden instanciar, pero si se pueden heredar.  Se puede implementar atributos, constructores y métodos.  También se puede declarar métodos abstractos.  Declaraciones con firmas de parámetros pero sin implementación.  Las declaraciones finalizan directamente con ;  Las clases derivadas están obligadas a implementarlos con el mismo nombre y firma de parámetros.
  13. 13. CLASES ABSTRACTAS II
  14. 14. REDEFINICIÓN  Las clase derivadas pueden redefinir o sobrescribir métodos (Override)  Se puede volver a implementar un método de la clase base en la clase derivada.  Para diferenciar el acceso de la implementación de la clase base o la clase derivada se puede utilizar las palabras reservadas:  super  this
  15. 15. BIBLIOGRAFÍA TEXTOS BÁSICOS 1 D. J. Eck; Introduction to Programming Using Java; 7a. ed.; 2016. 2 L 2 Cay S. Horstmann; Core Java Volume I—Fundamentals; 10a. ed.; 2015 3 Deitel P.j; Java : how to program, 9a. ed.; 2012 4 M. Ortiz, A. Plaza; Fundamentos de Programación en JAVA y UML; UPS Cuenca; 2014 5 Seidl, M., Scholz, M., Huemer, C., & Kappel, G.; UML@ classroom; Springer; 2015 LECTURAS SUGERIDAS 1 Martin, R. C. ; Código limpio. Editorial ANAYA; 2012 2 Johnson, R., & Vlissides, J. ; Design patterns. Elements of Reusable Object-Oriented Software Addison-Wesley, Reading; 1994 3 C. Fontela, C.; UML – Modelado de Software para profesionales; 2a. ed; 2012 4 J. Rumbaugh, I. Jacobson, Booch G.; The Unified Modeling Language Reference Manual; 2a. ed.; 2004

×