Diseo de Software

28 de febrero de 2012

Resumen de ideas para disear software de manera que resulte una herramienta til y no una
maraa ininteligible.

1. Algunos conociminetos previos

1.1. Diagramas UML
Pag. 232 en [1]

1.2. Abstracciones
1.2.1. Polimorfismo
???????

1.2.2. Interfaces
???????

2. Principios para el diseo gil

Principios basados en la programacin oriantada a objetos, para desarrollar software en forma
gil. Se basan principalmente en la idea de que se prevee que los requerimientos del software cambien
en el futuro.

2.1. Principio de responsabilidad nica

El ms importante, cada elemento debe tener una nica responsbilidad, que hay que indentificar
correctamente.

2.2. Principio de Apertura/Cerrazn

Los elementos deben estar abiertos para ser expandidos, pero cerrados para ser modificados. Es
decir que al cambiar los requerimientos pueda extenderse la funcionalidad de los elementos, pero sin
modificar el cdigo previo.
Esta idea se lleva al extremo al punto de pedir que un mdulo no sea tocado, el cdigo no sea
recompilado. Esto puede lograrse a travs de abstracciones: Generar clases base abstractas que luego
puedan usarse; utilizar interfaces.
O sea, que el mecanismo detras de este principio es el polimorfismo.

1
2.3. Principio de sustitucin de Liskov
Los subtipos deben ser sustituibles por sus tipos base. Si una funcin acepta una instancia de Ox
que es derivado de una clase abstracta OA, pero esa funcin no puede luego aceptar una instancia de
OA, significa que la funcin haca alguna clasificacin particular para identificar Ox, de manera que
ahora si le suministramos Oy 6= Ox, no sabe que hacer.
Aqu entonces vemos como la violacin de la sustitucin de Liskov ha provocado una violacin del
Principio de apertura/cerrazn, que es el problema ms importante que suele generar.

2.4. Principio de Inversin de Dependencias

Puede enunciarse a partir de los siguientes postulados:
1. Mdulos de alto nivel no deben depender de mdulos de bajo nivel. Ambos deben depender de
abstracciones.
2. Las aabstracciones no deben depender de los detalles.

As, cada clase define su propia interfaz abstracta que necesita que la clase en el nivel ms bajo
implemente, y se indpendiza de los mdulos de bajo nivel. stos ltimos se preocupan de cumplir con
la interfaz, y listo.
Idealmente, la interfaz es independiente tanto del cliente como del servidor. Ambos la utilizan para
comunicarse.

2.5. Principio de la Segragacin de la Interfaz

Las interfaces no deben contaminarse con mtodos que sirver slo a una subclase de la clase que
usa la interfaz.
Aqu es bueno notar que las responsailidades tampoco deben subirse a la clase base, porque generan
los mismos problemas que en la interfaz. La solucin es generar distintas interfaces para los distintos
clientes.

Referencias
[1] Robert Cecil Martin. Agile Software Development: Principles, Patterns, and Practices. Prentice Hall
PTR, Upper Saddle River, NJ, USA, 2003.