Diseño Orientado a Objetos

Diseño Orientado a Objetos

1. Principios del Diseño Orientado a Objetos

   • Principios generales
     • DRY (Don't Repeat Yourself) No te repitas
       • Reduce la dificultad en los cambios y en la evolución posterior
       • Promueve la reducción de la duplicación
     • KISS (Keep It Simple, Stupid) Mantenlo Simple
       • Aboga por la simplicidad como objeto vital, y por evitar cualquier complejidad innecesaria
       • Partes sencillas, comprensibles y con errores de fácil detección
   • Referidos a clases
     • Principio de responsabilidad única
       • Una clase debe tener una única causa por la cual puede ser modificada
       • Cada clase debe ser responsable de realizar una acción en el sistema
     • Principio abierto-cerrado
       • Las entidades de software (clases, módulos, funciones…) deben estar abiertas a la extensión y cerradas a la modificación
       • Se debería ampliar la funcionalidad de una clase sin necesidad de modificar su comportamiento interno
     • Principio de sustitución de Liskov
       • Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas
       • Se puede utilizar cualquier clase hija sin afectar el comportamiento de la clase padre
     • Principio de segregación de interfaces
       • Los clientes no deben ser forzados a depender de interfaces que no utlizan
     • Principio de inversión de dependencias
       • Las clases de alto nivel no deberían depender de las clases de bajo nivel
       • Consiste en inyectar comportamientos a componentes
   • Referidos a modulos
     • Cohesión
       • De Equivalencia entre Reutilización y Liberación
         • Clases que tienen un alto acoplamiento, se empaquetan juntas.
         • Es una agrupación de clases reutilizables que se puedan administrar y controlar cuando una nueva versión se genera.
       • De Cierre Común
         • Las clases que cambian juntas, pertenecen al mismo grupo.
         • Minimiza el impacto de un cambio para afectar la menor cantidad de paquetes posibles
       • De Reutilización Común
         • Las clases que no son rehusadas juntas, no deben juntarse en un paquete.
     • Acoplamiento
       • De Dependencias Acíclicas
         • La estructura de dependencias de un paquete debe ser un Grafo acíclico dirigido.
         • No debe tener dependencias cíclicas con otros paquetes
       • De Dependencias Estables
         • La dependencia de paquetes debe ser en dirección de la estabilidad de los paquetes.
         • Un paquete solo debe depender de paquetes que son más estables que él para que el paquete sea fácil de cambiar
       • De Abstracción Estable
         • Los paquetes estables deben ser paquetes abstractos
         • Los paquetes inestables arriba y los estables debajo. Luego, todas las dependencias apuntan hacia abajo

2. Técnicas del Diseño Orientada a Objetos

   • Analisis del comportamiento
     • Se forman clases basadas en grupos de objetos que exhiben comportamiento similar
     • Agrupan cosas que tienen responsabilidades comunes
     • Se forman jerarquías de las superclases que incorporan responsabilidades generales y subclases que especializan su comportamiento
   • Análisis de dominios
     • Busca identificar las clases y objetos comunes a todas las aplicaciones dentro de un dominio dado.
     • Se intenta identificar los objetos, operaciones y relaciones con los expertos del dominio consideran importantes acerca del mismo.
   • Análisis de casos de uso
     • Una forma o escenario concreto de uso paso por paso.
     • Comienza con algún usuario del sistema que inicia alguna secuencia de eventos interrelacionados