Patrones y principios de diseño PDF

Preview

Summary

Apuntes de patrones...

Description

PATRONES Y PRINCIPIOS DE DISEÑO DEL SOFTWARE APUNTES 2º CURSO GRADO EN INGENIERÍA INFORMÁTICA UDC (UNIVERSIDAD DE LA CORUÑA) (AÑO 2016-2017)

COMPILANDO-ES

© http://www.compilando-es.blogspot.es.com/ & UDC

TEMA 1: PRINCIPIOS DISEÑO MALOLIENTE El objetivo de seguir unos principios y patrones de diseño de software es evitar el código maloliente, es decir, aquel que es ilegible y que un pequeño cambio en una parte de la implementación causa la rotura de todo el software. Un código es maloliente cuando existe código 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 métodos de otras constantemente), intimidad inapropiada (parte de su implementación está en otras clases), rechace del legado (sobrescribir un método que no concuerde con la clase madre), métodos demasiado grandes, muchas secuencias switch, muchos parámetros en el método, grandes cúmulos 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 código), inmobilidad (muy dificil separar el sistema en componentes), viscosidad y complejidad innecesaria (hacer un acto de sobreengenieria, haciendo las cosas mucho más dificiles de lo que realmente son), repetición continua (de código y estructuras) y opacidad (dificil de leer y comprender). PRINCIPIOS DE DISEÑO Guia que hace más sencillo al programador desarrollar el código, cambiarlo y extenderlo. PRINCIPIOS SOLID: 5 principios básicos para simplificar y mejorar un código: • •

•

RESPONSABILIDAD ÚNICA: Cada objeto debe tener una única responsabilidad dentro del código. Por ejemplo, si un rectángulo tiene una aplicación geométrica y otra gráfica, separar entre rectángulo geométrico y rectángulo gráfico. ABIERTO CERRADO: Una entidad (clase) debe ser abierta en cuanto a permitir su extensión, 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 según 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(). SUSTITUCIÓN DE LISKOV: Las clases derivadas (hijas) pueden ser sustituibles por la base (madre). Es decir, aquellos métodos 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 método getNombre() podrá ser utilizado por los diferentes tipos de sueldo sin que el cliente lo sepa.

© http://www.compilando-es.blogspot.es.com/ & UDC

SUBCONTRATACIÓN: Al redefinir un método de una clase base (madre), solo lo haremos si al modificar su precondición la hacemos más débil y la postcondición más severa. Por ejemplo (en UML):

•

INVERSIÓN DE DEPENDENCIA: Depende de la abstracción, no de la concretación. Es la técnica 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 implementación de la lista en un momento dado en el código, unicamente cambiandolo por List lista = new LinkedList(). PROBLEMA: Al obviar implementación podemos estar llamando anteriormente a un método que solo haya en ArrayList y no en todos los List (como ensureCapacity), lo cual retornaría fallo de compilación.

•

SEGREGACIÓN DE INTERFACES: Varios interfaces específicos para cada clase son mejores que uno genérico para todas, siempre y cuando no sean de tipos iguales. Por ejemplo, es mejor los interfaces Repartidor, Becario, Jefe y Oficinista que uno común Trabajador, ya que el Repartidor tiene métodos que no tiene Jefe.

© http://www.compilando-es.blogspot.es.com/ & UDC

TIPOS DE HERENCIA: ADECUADOS: •

ESPECIALIZACIÓN: Las subclases sobrescriben métodos 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 método sueldo() se sobrescriben por cada grupo para especificarlo.

•

ESPECIFICACIÓN: La clase padre define un método 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 Círculo, Rectángulo, Triángulo… EXTENSIÓN: La subclase no sobrescribe nada, simplemente añade nuevas funcionalidades. Por ejemplo, la clase Cuadrado puede tener la subclase CuadradoColoreado con un nuevo atributo color y un método colorear(), pero es el mismo cuadrado sin cambiar el cuadrado.

•

NO ADECUADOS: •

• •

•

CONSTRUCCIÓN: 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 podría heredar de Vector PERO una pila no es un vector y causaría problemas. VARIANZA: Implementaciones similares pero no poseen jerarquia. Por ejemplo, Cuadrado y Rectángulo, ninguna es madre de la otra. Son hermanas y su madre debería ser Paralelogramo. LIMITACIÓN: Comportamiento de la subclase más restrictivo que el de la superclase. Por ejemplo, Pila podría implementar todos los métodos que no use de Vector mediante excepciones (USO MUY INADECUADO) COMBINACIÓN: Cuando existe la herencia múltiple, una clase hereda de más 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 patrón de diseño es una solución general y reusable a un problema recurrente dentro de un determinado contexto. TIPOS DE PATRONES: -

ARQUITECTÓNICOS: Organización estructural del software, basándose en las responsabilidades y relaciones. DISEÑO: Resuelven problemas de diseño 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 antipatrón “Clase Dios”. PATRONES DE DISEÑO BÁSICOS: ➢ PRINCIPIO “FAVORECE LA INMUTABILIDAD”: Las clases deben ser inmutables a no ser que haya una buena razón para hacerlas mutables •

PATRÓN INMUTABLE: Basándonos en el principio anterior, intentamos que nuestra clase sea inmutable siempre que se pueda. Para ello hay que seguir ciertas reglas obvias: ◦ ◦ ◦ ◦ ◦

•

Evitar los métodos 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 VARÍA”: Identifica los aspectos del código que varían y separalos del resto que permanecen estables. •

PATRÓN ESTRATEGIA: Patrón de comportamiento, que encapsula, define y hace intercambiables varios algoritmos de una determinada familia.

©

C

•

PATRÓN ESTADO: Patrón 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 diseños debilmente acoplados que interactúen entre ellos. El acoplamiento es la medida de dependencia entre varias clases del sistema. •

PATRÓN OBSERVADOR: Permite definir una dependencia UNO A MUCHOS entre varios objetos, de manera que cuando el objeto cambie de estado sea notificado y actualizado automáticamente.

© http://www.compilando-es.blogspot.es.com/ & UDC

El patrón observador tiene ya sus implementaciones básicas en el API de Java, Observable y Observator, donde básicamente el Observador tiene un método actualizar. Este interfaz Observador debe ser implementado sobre la clase ObservadorConcreto que espera la notificación. Por otro lado, el Sujeto (Observable) es el observado, el cual debe incluir un método para notificar al observador, además 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 notificación. El update es basicamente la solución 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 notificación mínima de cambio de estado. Su ventaja es que enfatiza la ignorancia típica de la OO. PUSH: El sujeto empuja a los observadores, dándoles información detallada de lo que ha cambiado, siendo el sujeto aquel que precisa conocer todos sus cambios internos. Su ventaja es la posible eficiencia del código, aunque tienen mayor dependencia sujetoobservador.

© http://www.compilando-es.blogspot.es.com/ & UDC

•

PATRÓN ADAPTADOR: Es un patrón que permite, mediante un interfaz, relacionar otro interfaz y el cliente, siendo estos “incompatibles”. MEDIANTE HERENCIA

MEDIANTE COMPOSICIÓN

ADAPTADOR POR HERENCIA MÚLTIPLE: 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 COMPOSICIÓN: Adapta los objetos. Permite adaptar clases y subclases. Es más 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 MÍNIMO CONOCIMIENTO (LEY DE DEMETRER): Reduce el número de relaciones, evitando hablar con “extraños”. Un objeto debe saber lo mínimo sobre estructura y propiedades de otros. Desntro de un objeto solo te debes relacionar contigo mismo (this), los parámetros de un método, atributo de tu objeto, un elemento de colección que es atributo de tu objeto y un objeto creado dentro del método. ➢ PRINCIPIO “TELL, DON’T ASK”: La orientación a objetos le dice a sus objetos lo que quieren que hagan. •

PATRÓN FACHADA: Provee un interfaz de unión de diferentes subsistemas. Hacemos una composición de todas las clases sobre una única clase que realiza una acción.

•

PATRÓN COMPOSICIÓN: Patrón estructural que se utiliza para componer objetos en estructuras de árbol que representan jerarquias todo-parte. Este patrón permite tratar uniformemente a objetos y composiciones.

EJEMPLO:

©

•

PATRÓN ITERADOR: Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado (una colección) sin exponer su representación interna.

En el API ya existe un Iterable (función de Agragado) e Iterator (función de Iterador). EJEMPLO CON CLASES INTERNAS: (CREANDO LA CLASE ITERADORCONCRETO EN AGREGADO CONCRETO):

•

MÉTODO FACTORÍA: Define una interfaz para crear un objeto (constructor) permitiendo que las clases decidan que objeto crear.

©h

DC

•

PATRÓN CONSTRUCTOR: Separa la construcción de un constructor con su representación. Intentar evitar en el constructor el antipatrón telescopio, con un constructor de elevado número de parámetros.

•

PATRÓN MÉTODO PLANTILLA: Define el esqueleto del algoritmo en una operación 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 método plantilla. ➢ PRINCIPIO KISS: KEEP IT SIMPLE, STUPID → Las complejidades innecesarias deben ser evitadas. ➢ PRINCIPIO YAGNI: YOU AREN’T GONNA NEED IT → Implementa los cambios que realmente necesitarás.

© http://www.compilando-es.blogspot.es.com/ & UDC...