Programación Orientada a Objetos (POO)

Programación Orientada a Objetos (POO)

1. Abstracción

   • Llevar lo más importante del mundo real a código computacional
   • Depende del contexto en el que se esté trabajando

2. Clases

   • Concepto a ser usado dentro de nuestro programa
   • Los objetos derivan de las clases
   • Estructura
     • Atributos / Campos
       • Se refiere a las características que posee la clase
       • Nivel de acceso privado
       • Pueden ser modificados únicamente por métodos
     • Métodos
       • Hace referencia a los comportamientos que adopta la clase
       • Nivel de acceso público o privado
       • Delega responsabilidades
   • UML (Unified Modeling Languague)
     • Lenguaje estandarizado de modelado de clases

3. Encapsulamiento

   • Organización de datos
   • Definir los niveles de acceso
   • Evita malas prácticas de programación

4. TDD

   • 1) La prueba debe fallar
   • 2) Codificar lo mínimo para que el programa funcione
   • 3) La prueba debe ser exitosa
   • 4) Refactor

5. Aspectos a resaltar

   • This : Hace referencia a la clase en la que se encuentra
   • Clean Code
     • Legibilidad
     • Línea de código principal debe estar en nivel 1
   • Instanciar
     • Almacenar dentro de la dirección de memoria asignada
   • Ennumeraciones
     • Enumerar aspectos constantes del código
   • Alta Cohesión / Bajo Acoplamiento

6. Herencia

   • Características / Comportamientos heredados de padre a hijo
     • Polimorfismo
       • Cambios dentro de lo heredado
     • Clase Padre / Base
       • Más abstracto
       • Si es abstracta, no se puede instanciar
     • Clase Hija
       • Más concreta (real)
       • Extiende los atributos y comportamientos de la clase padre
   • "Extends"

7. Interfaces

   • Contiene únicamente métodos abstractos
   • Se sabe que se debe hacer, más no el como hacerlo
   • Debe cumplir un contrato
   • "Implements"

8. Principios SOLID

   • Responsabilidad Unica
   • Abierto / Cerrado
     • Abierto a extenderse pero cerrado a modificarse
   • Sustitución de Liskov
     • Clases hijas deben poder ser reemplazadas por las clases padres
   • Inversión de Dependencias
     • Se depende de abstracciones mas no de aspectos concretos
   • Segregación de Interfaces
     • Es mejor algo específico que algo genérico

9. Ciclo de vida de desarrollo de software (CVDS)

   • Planificación
   • Análisis de requisitos
   • Diseño
   • Fase de pruebas
   • Mantenimiento

Imágenes y archivos del mapa