Page 1

UNIVERSIDAD LATINA

Profesor: James F. Mcintosh Programaci贸n IV

POO


Patrones de Dise単o


Objetivo Los patrones de diseño pretenden: 

Proporcionar catálogos de elementos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario común entre diseñadores.


Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.


Asimismo, no pretenden: 

Imponer ciertas alternativas de diseño frente a otras. Eliminar la creatividad inherente al proceso de diseño.


Antipatrones dise単o OO


Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.

BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella. Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no añade modificación alguna. Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito.

Modelo de dominio anémico (anemic domain model): Usar un modelo del dominio sin ningunalógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado.


Objeto sumidero (object cesspool): Reusar objetos no adecuados realmente para el fin que se persigue. Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase). Poltergeist: Emplear objetos cuyo único propósito es pasar la información a terceros objetos. Problema del círculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos. Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación. Singletonitis: Abuso de la utilización del patrón singleton. YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.


Antipatrones de programaci贸n


Nomenclatura heroica (heroic naming): Identificar los miembros de un programa (interfaces, clases, propiedades, métodos...) con nombres que provocan que el conjunto aparente estandarización con la ingeniería del software pero que en realidad oculta una implementación anárquica. Acción a distancia (action at a distance): Provocar la interacción no prevista de componentes muy distantes de un sistema. Acumular y arrancar (accumulate and fire): Establecer una colección de variables globales para ser usadas por un conjunto de subrutinas.

Ancla del barco (boat anchor): Retener partes del sistema que ya no tienen utilidad. Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas.


Código duro (hard code): Hacer supuestos sobre el entorno del sistema en demasiados lugares de la implementación.

Complejidad no indispensable (accidental complexity): Dotar de complejidad innecesaria a una solución.

Código espagueti (spaghetti code): Construir sistemas cuya estructura es difícilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.

Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy débilmente conectados.

Comprobación de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un objeto es de un tipo concreto cuando lo único que se necesita es verificar si cumple un contrato determinado.


Abstracci贸n


“Acción de aislar mentalmente o considerar por separado las cualidades de un objeto, considerar un objeto en su esencia"


¿Qué quiere decir esta definición? A través de la abstracción conseguimos

extraer las cualidades principales sin detenernos

en

los

detalles.

Conseguimos a partir de un tema

determinado, generalizar y obtener una visión global del tema.


Encapsulamiento


“Es el empaquetamiento de las variables de un objeto con la protección de sus métodos.”


TĂ­picamente, el encapsulamiento es utilizado para esconder detalles de la puesta en prĂĄctica no importantes de otros objetos. Entonces, los detalles de la puesta en prĂĄctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.


public class MiClase{ public int tipo; } class AccesoDirecto{ public static void main(String[] args){ MiClase mc = new MiClase(); mc.tipo = -5; //1 } }


public class MiClase{ private int tipo; public void setTipo(int t){ tipo = t; } public int getTipo(){ return tipo; } } class AccesoIndirecto{ public static void main(String[] args){ MiClase mc = new MiClase(); mc.setTipo(5); System.out.println("El tipo es:" + mc.getTipo()); } }


Modularidad


Mediante la modularidad, se propone al programador dividir su aplicaci贸n en

varios m贸dulos diferentes (ya sea en forma

de

clases,

paquetes

o

bibliotecas), cada uno de ellos con un

sentido propio.


Esta fragmentaci贸n disminuye el grado de dificultad del problema al que da

respuesta el programa, pues se afronta el problema como un conjunto de problemas de menor dificultad, adem谩s

de

facilitar

programa.

la

comprensi贸n

del


Acoplamiento


• Dos elementos están acoplados en la medida en el que los cambios en uno

tienden a necesitar cambios en el otro. • Por ejemplo, la comunicación por red

entre

dos

sistemas

está

acoplada

respecto a cambios en el protocolo - si un

sistema

necesita

cambiar

el

protocolo, el otro va a necesitar cambiar también. El acoplamiento entre

los

elementos

conductor de cambios.

es

un


Cohesi贸n


El acoplamiento mide la dispersi贸n del cambio a trav茅s de los elementos. La

cohesi贸n mide el costo del cambio dentro de un elemento. Un elemento es cohesivo a medida que cambia el

elemento entero cuando el sistema necesita cambiar.


Herencia


Es

el

mecanismo

fundamental

para

implementar la reutilización y extensibilidad del software. A través de ella los diseñadores pueden construir nuevas clases partiendo de una

jerarquía

de

clases

ya

existente

(comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos a partir de otros ya

existentes,

obteniendo

características

(métodos y atributos) similares a los ya existentes.


public class Mamifero{ private int patas; private String nombre; public void imprimirPatas(){ JOptionPane.showMessageDialog(null," Tiene " + patas + "patas\n","Mamifero",JOptionPane.INFORMATION_MESSAGE); } public Mamifero(String nombre, int patas){ this.nombre = nombre; this.patas = patas; } } public class Perro extends Mamifero { public Perro(String nombre){ super(nombre, 4); } } public class Gato extends Mamifero { public Gato(String nombre){ super(nombre, 4); } }


public class CrearPerro { public static void main(String [] args) { Perro perrito = new Perro("Canelita"); perrito.imprimirPatas(); /*EstĂĄ en la clase mamĂ­fero*/ } }


Composici贸n


“Hay dos formas de reutilizar el

código, mediante la composición y

mediante

composición

la

herencia.

significa

La

utilizar

objetos dentro de otros objetos.”


Diferencia: Herencia vrs Composición La relación “es-un” viene expresada

por la herencia, y la relación “tieneun”

viene

composición.

expresada

por

la


Delegaci贸n


Es una técnica en la que un objeto de cara al exterior expresa cierto comportamiento pero en realidad delega la responsabilidad de implementar dicho comportamiento a un objeto asociado.

El patrón de diseño de Delegación es la abstracción fundamental que da soporte a la composición.


Reutilizaci贸n

Ejemplo  
Read more
Read more
Similar to
Popular now
Just for you