Patrones de diseño Diseño de Software Orientado a Objetos



Descargar 23.67 Kb.
Fecha de conversión28.02.2018
Tamaño23.67 Kb.

Patrones de diseño

Diseño de Software Orientado a Objetos


Por Joaquin Gracia
27 de Mayo de 2005


Patrones de diseño o más comúnmente conocidos como "Design Patterns". ¿Qué son los patrones de diseño? Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.

Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más comunes y conocidos.

Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos.

A continuación una lista con los patrones de diseño a objetos más habituales publicados en el libro "Design Patterns", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro").


Patrones de creación



  • Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.

  • Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.

  • Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.

  • Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.

  • Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales



  • Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.

  • Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.

  • Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.

  • Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.

  • Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.

  • Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.

  • Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento



  • Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.

  • Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.

  • Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.

  • Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.

  • Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.

  • Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.

  • Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.

  • State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.

  • Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.

  • Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.

  • Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.


PATRON SINGLETON

Singleton: asegura que una clase sólo tenga una instancia, además provee de un punto global de control de acceso a este

Estructura

Diseña un sistema que tiene un spooler de impresión q maneja un conjunto de impresoras y un conj de documentos a imprimir

SPOOLER: es una clase que debe tener una sola instancia, el SINGLENTON pide que se cancele el metodo new() o se lo redefina.


Detectar que una clase tenga sobrescrito el metodo new (creación de objeto) y que exista una variable dentro de una clase que se llame unique intance.

Sobrescribir el método New()

New{ if unique instance no es nula

Then return unique instance

Else unique instance:= ‘SPOOLER nueva Instancia’ }

Esto es SINGLETON por convensión


En el siguiente ejemplo crearemos una clase que inicialice y retorne un objeto conexión si no existe y si ya existen que nos retorne la instancia existente.



COMPOSITY
Para detectar un composity debe haber:


    • Mínimo tres clases ( la super clase tiene que ser abstractas y las dos subclases concretas)

    • Herencia entre las tres clases

Este patrón trata de forma uniforme elementos simples y compuestos. Estructuras complejas recorren los árboles como no son tan eficaces en tiempo, para guardar los objetos y referencias ( de que clase era) esta es la razon por lo que las bases de datos orientadas a objetos en relación a la persistencia no han tenido éxito.


Estructura

1) Diseñar un sistema de archivos como el explorador de windows


C:\windows\

Temp\ txt1.txt

\ doc.doc

Command.com

ARCHIVO.Size( Return byte )
DIRECTORIO.Size( for each componente de c

Total:= total + c.size

Return total )
2)

3)

4) Los menús que contienen elementos de menú, cada uno de ellos podría ser un menú. (COMPOSITE)

Strategy
Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varie independientemente de los clientes que lo usan.
Este patrón permite que el algoritmo a ejecutarse se seleccione en tiempo de ejecución. Este algoritmo proporciona una familia de algoritmos, encapsula cada uno dentro de un objeto y los hace intercambiables. Esto permite que el algoritmo a ejecutarse varíe en función del cliente que lo use.
Usa el patrón Strategy cuando:

- Varias clases relacionadas sólo difieren en su comportamiento. Strategy permite configurar a una clase con uno de entre varios comportamientos

- Se necesiten variantes del mismo algoritmo, que se implementan como una jerarquía de clases

- Un algoritmo usa datos que los clientes no tienen por qué conocer (ej. estructuras de datos específicas del algoritmo)

- Una clase define muchos comportamientos que aparecen en sentencias condicionales mover los relacionados a un strategy

- Strategy (Compositor): define una interfaz común a los algoritmos que soporta.

- ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor): implementa un algoritmo usando la interfaz Strategy

- Context (Composition):

- Está configurado con un objeto ConcreteStrategy

- Mantiene una referencia al objeto Strategy

- Puede definir una interfaz que le permita a Strategy acceder a sus datos

Ejemplos


1)

El frenar de CocheAntiguo llama a FrenadoNormal y CocheNuevo a FrenadoABS


2)



La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal