PATRONES Y PRINCIPIOS DE DISEO DEL

SOFTWARE
APUNTES 2 CURSO GRADO EN INGENIERA INFORMTICA
UDC (UNIVERSIDAD DE LA CORUA)
(AO 2016-2017)

COMPILANDO-ES

http://www.compilando-es.blogspot.es.com/

& UDC

TEMA 1: PRINCIPIOS
DISEO MALOLIENTE
El objetivo de seguir unos principios y patrones de diseo de software es evitar el cdigo
maloliente, es decir, aquel que es ilegible y que un pequeo cambio en una parte de la
implementacin causa la rotura de todo el software.
Un cdigo es maloliente cuando existe cdigo igual duplicado, cuando existe la llamada clase Dios
(una clase grande que hace practicamente todo ella sola), existen clases perezosas (hacen muy poco
cada una), clases de datos (solo aportan datos a la clase Dios), existe envidia (una clase usa los
mtodos de otras constantemente), intimidad inapropiada (parte de su implementacin est en otras
clases), rechace del legado (sobrescribir un mtodo que no concuerde con la clase madre), mtodos
demasiado grandes, muchas secuencias switch, muchos parmetros en el mtodo, grandes cmulos
de datos (que podrian estar en otro tipo de clases)
Las principales consecuencias son la rigidez ante los cambios, la fragilidad (los cambios causan
ruptura de cdigo), inmobilidad (muy dificil separar el sistema en componentes), viscosidad y
complejidad innecesaria (hacer un acto de sobreengenieria, haciendo las cosas mucho ms dificiles
de lo que realmente son), repeticin continua (de cdigo y estructuras) y opacidad (dificil de leer y
comprender).
PRINCIPIOS DE DISEO
Guia que hace ms sencillo al programador desarrollar el cdigo, cambiarlo y extenderlo.
PRINCIPIOS SOLID:
5 principios bsicos para simplificar y mejorar un cdigo:

RESPONSABILIDAD NICA: Cada objeto debe tener una nica responsabilidad dentro
del cdigo. Por ejemplo, si un rectngulo tiene una aplicacin geomtrica y otra grfica,
separar entre rectngulo geomtrico y rectngulo grfico.
ABIERTO CERRADO: Una entidad (clase) debe ser abierta en cuanto a permitir su
extensin, pero cerrada frente a modificaciones. Es decir, queremos modificar las cosas sin
necesidad de tocar el de otras clases. Por ejemplo, en una empresa existen 3 tipos de
trabajadores segn la forma de su salario. Cuando queremos introducir otro tipo de salario,
unicamente deberiamos crear una nueva clase sin modificar el resto de clases, en este caso
se haria con una clase madre Trabajador y 4 clases que la heredan y sobrescriben sueldo().
SUSTITUCIN DE LISKOV: Las clases derivadas (hijas) pueden ser sustituibles por la
base (madre). Es decir, aquellos mtodos que utilicen referencias a clases base deberian
funcionar al usar clases derivadas sin saberlo. Por ejemplo, el caso anterior de Trabajador, si
este tiene un mtodo getNombre() podr ser utilizado por los diferentes tipos de sueldo sin
que el cliente lo sepa.

http://www.compilando-es.blogspot.es.com/

& UDC

SUBCONTRATACIN: Al redefinir un mtodo de una clase base (madre), solo lo haremos

si al modificar su precondicin la hacemos ms dbil y la postcondicin ms severa. Por
ejemplo (en UML):

INVERSIN DE DEPENDENCIA: Depende de la abstraccin, no de la concretacin. Es

la tcnica que permite depender en un primer lugar de funciones abstractas como interfaces
y no de clases concretas. Por ejemplo, en caso de List y ArrayList:
Si tenemos un arraylist de la forma: ArrayList array= new ArrayList()
se puede convertir a la forma:
List array= new ArrayList()
De esta forma operamos con una clase abstracta. Seria muy sencillo cambiar la
implementacin de la lista en un momento dado en el cdigo, unicamente cambiandolo por
List lista = new LinkedList().
PROBLEMA:
Al obviar implementacin podemos estar llamando anteriormente a un mtodo que solo
haya en ArrayList y no en todos los List (como ensureCapacity), lo cual retornara fallo de
compilacin.

SEGREGACIN DE INTERFACES: Varios interfaces especficos para cada clase son

mejores que uno genrico para todas, siempre y cuando no sean de tipos iguales. Por
ejemplo, es mejor los interfaces Repartidor, Becario, Jefe y Oficinista que uno comn
Trabajador, ya que el Repartidor tiene mtodos que no tiene Jefe.

http://www.compilando-es.blogspot.es.com/

& UDC

TIPOS DE HERENCIA:
ADECUADOS:

ESPECIALIZACIN: Las subclases sobrescriben mtodos para especializar y concretar el

comportamiento de estos respetando las especificaciones de la clase base. Por ejemplo, los
diferentes sueldos en una empresa dados por el mtodo sueldo() se sobrescriben por cada
grupo para especificarlo.

ESPECIFICACIN: La clase padre define un mtodo que no implementa (en forma de

conducta) para que sus subclases la implementen. Por ejemplo, la clase abstracta Figura
definir area() o perimetro() pero no ser implementada por l, sino por sus subclases
Crculo, Rectngulo, Tringulo
EXTENSIN: La subclase no sobrescribe nada, simplemente aade nuevas
funcionalidades. Por ejemplo, la clase Cuadrado puede tener la subclase CuadradoColoreado
con un nuevo atributo color y un mtodo colorear(), pero es el mismo cuadrado sin cambiar
el cuadrado.

NO ADECUADOS:

CONSTRUCCIN: Usa el comportamiento de la superclase pero no sigue la norma ES

UN. Por ejemplo, Pila y Vector son clases que almacenan el valor de una forma similar por
lo que Pila podra heredar de Vector PERO una pila no es un vector y causara problemas.
VARIANZA: Implementaciones similares pero no poseen jerarquia. Por ejemplo, Cuadrado
y Rectngulo, ninguna es madre de la otra. Son hermanas y su madre debera ser
Paralelogramo.
LIMITACIN: Comportamiento de la subclase ms restrictivo que el de la superclase. Por
ejemplo, Pila podra implementar todos los mtodos que no use de Vector mediante
excepciones (USO MUY INADECUADO)
COMBINACIN: Cuando existe la herencia mltiple, una clase hereda de ms de una
clase. En Java no est permitida y se cambia por un uso de interfaces.

http://www.compilando-es.blogspot.es.com/

& UDC

TEMA 2: PATRONES
Un patrn de diseo es una solucin general y reusable a un problema recurrente dentro de un
determinado contexto.
TIPOS DE PATRONES:
-

ARQUITECTNICOS: Organizacin estructural del software, basndose en las

responsabilidades y relaciones.
DISEO: Resuelven problemas de diseo refinando subsistemas.
IDIOMAS: Explica como implementar sucesos particulares dentro de un lenguaje concreto.

ANTIPATRONES:
Representan aquellas soluciones recurrentes a un problema que obtienen consecuencias negativas,
como el antipatrn Clase Dios.
PATRONES DE DISEO BSICOS:
PRINCIPIO FAVORECE LA INMUTABILIDAD: Las clases deben ser inmutables a no
ser que haya una buena razn para hacerlas mutables

PATRN INMUTABLE: Basndonos en el principio anterior, intentamos que nuestra clase

sea inmutable siempre que se pueda. Para ello hay que seguir ciertas reglas obvias:

Evitar los mtodos tipo set

Hacer que la clase no pueda ser extendida
Declarar los atributos como final
Declarar los atributos como privados
Evitar el acceso a componentes internos mutables

INSTANCIA NICA: Cada clase tiene una nica instancia y proporciona un punto global de
acceso a ella.
Definimos un atributo como la propia instancia y hacemos que el constructor sea privado.

PRINCIPIO ENCAPSULA LO QUE VARA: Identifica los aspectos del cdigo que
varan y separalos del resto que permanecen estables.

PATRN ESTRATEGIA: Patrn de comportamiento, que encapsula, define y hace

intercambiables varios algoritmos de una determinada familia.

http://www.compilando-es.blogspot.es.com/

& UDC

PATRN ESTADO: Patrn de comportamiento que permite a un objeto cambiar de

conducta al cambiar el estado interno.

Es importante que en el contexto aparezca un Estado que ir siendo modificado, y cada

estado concreto tenga una instancia nica ya creada, un getInstancia que devuelva esa
instancia y el constructor.
PRINCIPIO DEL BAJO ACOPLAMIENTO: Busca diseos debilmente acoplados que
interacten entre ellos. El acoplamiento es la medida de dependencia entre varias clases del
sistema.

PATRN OBSERVADOR: Permite definir una dependencia UNO A MUCHOS entre varios
objetos, de manera que cuando el objeto cambie de estado sea notificado y actualizado
automticamente.

http://www.compilando-es.blogspot.es.com/

& UDC

El patrn observador tiene ya sus implementaciones bsicas en el API de Java, Observable y

Observator, donde bsicamente el Observador tiene un mtodo actualizar. Este interfaz
Observador debe ser implementado sobre la clase ObservadorConcreto que espera la
notificacin. Por otro lado, el Sujeto (Observable) es el observado, el cual debe incluir un
mtodo para notificar al observador, adems de crear y eliminar observadores El
SujetoConcreto deber heredar de la clase Sujeto y tener sus propias funciones de
comportamiento. En estas funciones es donde se suele dar la notificacin. El update es
basicamente la solucin a los problemas.
PULL: Los observadores tiran del sujeto, siendo ellos los que tienen que indagar qu ha
cambiado ya que el sujeto da una notificacin mnima de cambio de estado.
Su ventaja es que enfatiza la ignorancia tpica de la OO.
PUSH: El sujeto empuja a los observadores, dndoles informacin detallada de lo que ha
cambiado, siendo el sujeto aquel que precisa conocer todos sus cambios internos.
Su ventaja es la posible eficiencia del cdigo, aunque tienen mayor dependencia sujetoobservador.

http://www.compilando-es.blogspot.es.com/

& UDC

PATRN ADAPTADOR: Es un patrn que permite, mediante un interfaz, relacionar otro

interfaz y el cliente, siendo estos incompatibles.
MEDIANTE HERENCIA

MEDIANTE COMPOSICIN

ADAPTADOR POR HERENCIA MLTIPLE: Adapta las clases. Solo permite adaptar a su
clase, no a sus subclases. Permite que el adaptador sobrescriba parte del comportamiento de
la clase original, pero solo se puede usar si Objetivo es interfaz y no clase abstracta.
ADAPTADOR POR COMPOSICIN: Adapta los objetos. Permite adaptar clases y
subclases. Es ms compleja y solo funciona si Objetivo es una clase abstracta, no interfaz.
EJEMPLO: Vector vs Pila

http://www.compilando-es.blogspot.es.com/

& UDC

 PRINCIPIO DEL MNIMO CONOCIMIENTO (LEY DE DEMETRER): Reduce el nmero

de relaciones, evitando hablar con extraos. Un objeto debe saber lo mnimo sobre
estructura y propiedades de otros.
Desntro de un objeto solo te debes relacionar contigo mismo (this), los parmetros de un
mtodo, atributo de tu objeto, un elemento de coleccin que es atributo de tu objeto y un
objeto creado dentro del mtodo.
PRINCIPIO TELL, DONT ASK: La orientacin a objetos le dice a sus objetos lo que
quieren que hagan.

PATRN FACHADA: Provee un interfaz de unin de diferentes subsistemas. Hacemos una

composicin de todas las clases sobre una nica clase que realiza una accin.

PATRN COMPOSICIN: Patrn estructural que se utiliza para componer objetos en

estructuras de rbol que representan jerarquias todo-parte. Este patrn permite tratar
uniformemente a objetos y composiciones.

EJEMPLO:

http://www.compilando-es.blogspot.es.com/

& UDC

PATRN ITERADOR: Proporciona un modo de acceder secuencialmente a los elementos

de un objeto agregado (una coleccin) sin exponer su representacin interna.

En el API ya existe un Iterable (funcin de Agragado) e Iterator (funcin de Iterador).

EJEMPLO CON CLASES INTERNAS: (CREANDO LA CLASE
ITERADORCONCRETO EN AGREGADO CONCRETO):

MTODO FACTORA: Define una interfaz para crear un objeto (constructor) permitiendo
que las clases decidan que objeto crear.

http://www.compilando-es.blogspot.es.com/

& UDC

PATRN CONSTRUCTOR: Separa la construccin de un constructor con su

representacin. Intentar evitar en el constructor el antipatrn telescopio, con un constructor
de elevado nmero de parmetros.

PATRN MTODO PLANTILLA: Define el esqueleto del algoritmo en una operacin pero
difiriendolo de sus subclases.

PRINCIPIO HOLLYWOOD: NO LLAME, YA LE LLAMAREMOS Desacopla distintos

elementos de alto y bajo nivel que interactuan juntos. El mejor ejemplo es el mtodo
plantilla.
PRINCIPIO KISS: KEEP IT SIMPLE, STUPID Las complejidades innecesarias deben
ser evitadas.
PRINCIPIO YAGNI: YOU ARENT GONNA NEED IT Implementa los cambios que
realmente necesitars.

http://www.compilando-es.blogspot.es.com/

& UDC