Principios de diseño OO

Vista previa del material en texto

01/06/2013
1
Principios de Diseño para Software 
Orientado a Objetos
Ing. Judith Meles
2Judith Meles
Características de un buen diseño
Independencia de los componentes
Identificación y tratamiento de excepciones
Prevención y tolerancia de defectos
01/06/2013
2
3Judith Meles
Independencia de los componentes
En la mayoría de los diseños se trata que los 
componentes sean independientes unos de 
otros.
Para reconocer y medir el grado de 
independencia de los componentes de un 
diseño se aplican dos conceptos:
Acoplamiento
Cohesión
4Judith Meles
Acoplamiento 
Dos componentes están altamente acoplados cuando 
existe mucha dependencia entre ellos. 
Los componentes poco acoplados, tienen algunas 
dependencias, pero las interconexiones entre ellos son 
débiles
Los componentes no acoplados no tienen interconexiones 
con el resto; son completamente independientes 
01/06/2013
3
5Judith Meles
Cohesión 
Se refiere al grado de interconexión interna con el 
que se ha construido el componente.
Un componente es cohesivo si todos sus 
elementos están orientados a la realización de una 
única tarea y son esenciales para llevarla a cabo.
6Judith Meles 6Judith Meles
Principio de Diseño
Un principio de diseño es 
una técnica o 
herramienta básica que 
puede ser aplicada para 
diseñar o construir 
software, para hacer 
más flexible, extensible 
y mantenible.
01/06/2013
4
7Judith Meles
Principios de Diseño Básicos
Flexibilidad: el software puede cambiar y crecer sin un 
constante re-trabajo. Evita la fragilidad del software.
Encapsulamiento: Mantiene las partes del software que 
son estables, lejos de las partes que cambian, entonces es 
fácil hacer cambios sin necesidad de romper todo.
Funcionalidad: Sin esto no importa que bien esté hecho el 
diseño, el cliente no estará feliz.
Uso de Patrones de Diseño: se trata de reuso y de no 
tratar de resolver un problema que ya resolvió alguien más.
8Judith Meles
Número 1: 
El principio Abierto - Cerrado
Es para permitir el cambio.
Y para permitirlo sin modificar lo existente.
Clases abiertas para extensión
Clases cerradas para modificación
Es a cerca de la flexibilidad.
01/06/2013
5
9Judith Meles
Número 2: El principio no te repitas
Evitar duplicaciones, abstrayendo cosas 
comunes y ubicándolas en un único lugar.
Se trata de ubicar un requerimiento en un ÚNICO 
lugar.
Tener cada pieza de información y 
comportamiento del sistema en un único lugar.
10Judith Meles
Número 3: 
El principio de responsabilidad única
Cada objeto del sistema debería tener una única 
responsabilidad.
Todos los servicios del objeto deberían focalizarse 
en ejecutar esa única responsabilidad.
Se cumple si cada objeto tiene un única razón 
para cambiar (cohesión).
01/06/2013
6
11Judith Meles
Ejemplo: Clase Automóvil
Responsabilidades Sigue el 
Principio
Viola el Principio
El automóvil se inicia a sí mismo  
El automóvil se detiene a sí mismo  
El automóvil se cambia el neumático a sí mismo  
El automóvil se conduce a sí mismo  
El automóvil se lava a sí mismo  
El automóvil se obtiene su nivel de aceite a sí mismo  
Análisis del Principio de responsabilidad única
12Judith Meles
Número 4: 
El principio de Sustitución de Liskov
Los subtipos deben ser sustituibles por sus tipos 
base.
Se refiere a la herencia bien diseñada.
Este principio revela problemas con la estructura 
de la herencia, si existieran.
01/06/2013
7
13Judith Meles
Ejemplo: 
14Judith Meles
Herencia frente a Realización
Conocido también como herencia de implementación frente a herencia de 
interfaz.
Hay que distinguir dos conceptos:
Clase: define como se implementa un objeto.
Tipo: sólo se refiere a su interfaz.
Herencia de clases: define la implementación de un objeto en términos de la 
implementación de otro. En resumen un mecanismo para compartir código o 
representación.
Herencia de interfaces: describe cuando se puede usar un objeto en lugar de 
otro.
La mayoría de los lenguajes no distinguen entre los dos tipos de herencia.
01/06/2013
8
15Judith Meles
Programar para interfaces no para una 
implementación
Herencia de clases es un mecanismo para extender la funcionalidad 
reutilizando de las clase padre. Permite definir un nuevo tipo de objeto 
basándose en otro.
Reusar la implementación es sólo la mitad de la historia. También es 
importante la capacidad de la herencia para definir familias de objetos 
con interfaces idénticas, al ser esto en lo que se basa el polimorfismo.
Si la herencia se usa con cuidado (correctamente), todas las clases que
derivan de una clase abstracta, compartirán su interfaz. Esto implica
que las subclases añaden o redefinen, no ocultan operaciones de la
clase padre.
16Judith Meles
Programar para interfaces no para una 
implementación
Manipular los objetos solamente en términos de la interfaz definida por 
las clases abstractas tiene dos ventajas:
Los clientes no tienen que conocer los tipos específicos de los objetos que 
usan, es suficiente con que éstos adhieran a la interfaz que esperan los 
clientes.
Los clientes desconocen las clases que implementan dichos objetos; solo 
conocen las clases abstractas que definen la interfaz.
Esto reduce las dependencias de implementación entre subsistemas.
No se deben declarar variables como instancias de clases concretas. 
En vez de eso, se ajustarán simplemente a la interfaz definida por una 
clase abstracta.
01/06/2013
9
17Judith Meles
La herencia no es la única opción…
Delegación: delegar comportamiento a otra clase cuando no quiere cambiar el 
comportamiento, pero no es su responsabilidad de sus objetos implementar 
ese comportamiento por si mismos.
Composición: puede reusar el comportamiento de una o más clases, y en 
particular de una familia de clases, con composición. El objeto posee 
completamente a los objetos compuestos y ellos no existen fuera del uso del 
objeto.
Agregación: Cuando se quieren los beneficios de la composición pero se utiliza 
el comportamiento de un objeto que existe más allá del objeto que lo usa.
Si se favorece la delegación, composición y agregación sobre la herencia, 
el software será generalmente, más flexible y fácil de mantener, extender 
y reusar.
18Judith Meles
Composición
La composición permite utilizar el comportamiento de una familia de 
otras clases, y cambiar ese comportamiento en tiempo de ejecución.
La composición es lo más poderoso cuando se quiere usar el 
comportamiento definido en una interfaz, y luego elegir de una 
variedad de implementaciones de la interfaz, tanto en tiempo de 
ejecución como en tiempo de compilación.
En la composición, el objeto compuesto de otros comportamientos 
posee estos comportamientos. Cuando el objeto se destruye, también 
sus comportamientos.
Los comportamientos en una composición no existen fuera de la 
composición en sí misma.
01/06/2013
10
19Judith Meles
Agregación vs. Composición
La forma de reconocerlas es hacer la siguiente 
pregunta: ¿El objeto cuyo comportamiento quiero 
usar existe fuera del objeto que usa ese 
comportamiento?
Si un objeto tiene sentido de existencia por si 
solo se debe usar: Agregación
De lo contrario usar: Composición
20Judith Meles
Herencia frente a composición
La reutilización mediante herencia se suele llamar “Reutilización de 
Caja Blanca”.
Se refiere a la visibilidad, con la herencia el interior de la clase padre suele 
hacerse visible a las subclases.
La composición es una alternativa, la funcionalidad se obtiene 
“ensamblando” objetos para obtener una funcionalidad más compleja. 
Este estilo se denomina “Reutilización de Caja Negra”
La visibilidad en este caso no ´posible dado que los detalles internos de los 
objetos no son visibles.
01/06/2013
11
21Judith Meles
Herencia frente a composición: 
Ventajas y desventajas
HERENCIA
Se define estáticamente en tiempo de 
compilación. 
Es sencilla de usar. 
Fácil de modificar la implementaciónque 
está siendo reutilizada.
No se puede cambiar la implementación 
en tiempo de ejecución.
Rompe el encapsulamiento.
Los cambios en la implementación del 
padre obligan a cambios en la 
implementación de las subclases.
COMPOSICIÓN
Se define dinámicamente en tiempo de 
ejecución.
Requiere de objetos con interfaces bien 
diseñadas, dado que a los objetos solo se 
accede por sus interfaces, no se rompe el 
encapsulamiento.
Los objetos se pueden reemplazar en tiempo 
de ejecución siempre que sean del mismo 
tipo.
Las dependencias de implementación son 
menores.
En un diseño así el comportamiento del 
sistema depende de las relaciones en lugar 
de estar definido en las clases. 
22Judith Meles
Delegación
Forma de lograr que la composición sea tan potente para la reutilización como 
la herencia.
Es cuando se transfiere la responsabilidad por una tarea particular a otra clase 
o método.
Se utiliza mejor cuando se quiere usar la funcionalidad de una clase tal cual 
es, sin cambiar su comportamiento para nada.
Es una alternativa a la herencia que no viola el principio de sustitución.
La principal ventaja es que sea fácil combinar comportamientos en tiempo de 
ejecución y cambiar la manera en la que éstos se combinan.
La desventaja es que el software dinámico y altamente parametrizado es más 
difícil de entender que el estático.
Es un ejemplo extremo de composición de objetos
01/06/2013
12
23Judith Meles 23Judith Meles
Ejemplo de Delegación
En lugar de pensar que Ventana “es un” Rectángulo, porque resulta que son 
rectangulares, ventana reusa el comportamiento de rectángulo, guardando una 
instancia de ésta en una variable y delegando en ella el comportamiento 
específico de los rectángulos. 
Dicho de otra forma: en lugar de que Ventana “sea un” rectángulo, Ventana
“contendrá” un rectángulo. Así Ventana debe reenviar las peticiones a su
instancia de rectángulo, mientras que antes habría heredado esas
operaciones.
24Judith Meles
Principios de Diseño Orientado a Objetos
Las clases se tratan de comportamiento y funcionalidad.
Diseños de bajo acoplamiento entre objetos que 
interactúan.
Depender de las abstracciones no de clases concretas.
Encapsular lo que varía.
Hablar solo con amigos
No nos llames, nosotros te llamamos o Principio de 
Control Invertido.
01/06/2013
13
25Judith Meles
Bibliografía
Design Patterns: Elements of Reusable Object-
oriented software. 
Gamma, Helm, Johnson, Vlissides
Head First Design Patterns. Freeman & Freeman
Head First Object-Oriented Analysis & Design. 
McLaughlin, Brett, Pollice Gary & West David.
26Judith Meles 26Judith Meles
Historia de Cambios
Fecha Versión Descripción Autor
31/07/2009 1.0 Versión Inicial Judith Meles
30/07/2011 1.1 Correcciones de formato y se agregan slides con conceptos de cohesión y acoplamiento Judith Meles