Alfredo Juarez » Patrones de Diseño http://www.alfrek.net/blog Web Design and Development Fri, 03 Dec 2010 20:06:52 +0000 en hourly 1 Symfony Components – Librerias PHP http://www.alfrek.net/blog/2009/09/symfony-components-librerias-php/ http://www.alfrek.net/blog/2009/09/symfony-components-librerias-php/#comments Tue, 22 Sep 2009 00:14:04 +0000 alfredojv http://www.alfrek.net/blog/?p=1273 symfony-components

La gente detrás de Symfony, uno de los Frameworks más usados por la comunidad PHP ha publicado una serie de librerias independientes, que prometen ayudar con el proceso de desarrollo de aplicaciones Web, en su web reza la siguiente frase:

The Symfony Components are standalone and reusable PHP classes. With no pre-requisite, except for PHP, you can install them today, and start using them right away. Currently, there are three components available at the moment.

Los componentes publicados hasta el momento son:

yaml

YAML – Una librerí­a que habla YAML
Symfony YAML es una libreria PHP que convierte cadenas YAML a arreglos PHP y viceversa.

event-dispatcher

Event Dispatcher – Facilitando la comunicación entre clases
Symfony Event Dispatcher es una librerí­a que provee de una implementación ligera del patrón de diseño Observer.

dependency-injection

Dependency Injection – Reinventando el manejo de clases
Symfony Dependency Injection es una librerí­a que provee un robusto contenedor de inyección de dependencias (Dependency Injection).

[Via WebAppers]

Start Slide Show with PicLens Lite PicLens]]> http://www.alfrek.net/blog/2009/09/symfony-components-librerias-php/feed/ 0 Strategy http://www.alfrek.net/blog/2008/07/strategy/ http://www.alfrek.net/blog/2008/07/strategy/#comments Mon, 21 Jul 2008 17:44:49 +0000 alfredojv http://www.alfrek.net/blog/?p=508 El patrón de diseño Strategy es de los más cruciales que existen en el diseño orientado a objetos. Se trata de crear componentes conectables, reemplazables y reusables.
Para explicar este patrón vamos a usar un ejemplo simple, que dicho sea de paso el uso de este patrón excede al ejemplo, pero es un buen intento para ayudar a comprenderlo.

Hola Mundo usando Strategy

El diagrama de clases UML muestra que la clase padre implementa las funciones genéricas representando las etiquetas HTML de inicio y fin. La clase hija HolaMundo implementa las funciones especí­ficas, representado por el contenido del documento. De esta manera, para generar algo más que un saludo, digamos un anuncio, podemos agregar otra clase hija, la cuál genera contenido de un anuncio.

Podemos mover el método getContents( ) a un objeto tipo Strategy, el cual utiliza HtmlDocument directamente en lugar de utilizar una subclase HtmlDocument. Tal y cómo lo muestra la siguiente figura.

Strategy

Cabe recalcar que estamos usando este ejemplo solo para entender los aspectos mecánicos de este patrón. HtmlContentStrategy podrí­a ser también una clase abstracta, pero lo hemos definido como una interfaz para dejar en claro que éste no necesita tener código.

Ahora veamos como pinta esto en código. La clase HtmlDocument todaví­a genera el inicio y comienzo del documento. Pero en lugar de obtener el contenido de un método que es aplicado en una subclase, éste lo obtiene del objeto Strategy.

Class HtmlDocument
{
	prí­vate $strategy;

	public function __construct( $strategy )
	{
		$this->strategy = $strategy;
	}

	public function getHtml( )
	{
		return “<html><body>”.$this->strategy->getContents( ).”</body></html>”;
	}
}

Queremos poder conectar diferentes objetos Strategy dentro del objeto HtmlDocument. Por lo que, el objeto HtmlDocument necesita una forma consistente de llamar al objeto Strategy. En otras palabras, éste necesita una interfaz consistente, la cuál es definidad por una interface.

interface HtmlContentStrategy
{
	public function __construct( $name );
	public function getContents( );
}

Ahora cualquier objeto HtmlDocument podrá usar cualquier objeto Strategy que implemente esta interfaz, ya que él solo requiere la habilidad para llamar al método getContents( ).

Pero, ¿qué pasa con el constructor? La interfaz lo define, también. El objeto Strategy para generar el mensaje “Hola Mundo” necesita la palabra “Mundo” como argumento en el constructor. Pero, ¿estamos seguros que otro objeto necesitará la misma palabra? Me temo que no; de hecho, pienso que necesitarán todo tipo de información para hacer su trabajo.

Para contrarestar este problema, solo eliminamos el constructor de la interface. Desde que HtmlDocument no instancia la clase Strategy, todos los objetos que implementan la interfaz pueden ser usados aún y cuando los constructores difieren. Así­ que la interfaz solo necesita el método getContents( ).

interface HtmlContentStrategy
{
	public function getContents( );
}

Ahora podemos implementar el “Hola Mundo” como una clase Strategy:

class HolaMundoStrategy implements HtmlContentStrategy
{
	var $mensaje;

	public function __construct( $mensaje )
	{
		$this->mensaje = $mensaje;
	}

	public function getContents( )
	{
		return "Hola ".$this->mensaje . "!";
	}
}

Lo que esta clase hace es trivial, pero el patrón es extremadamente usable en situaciones más complejas.

]]> http://www.alfrek.net/blog/2008/07/strategy/feed/ 2 DAO: Data Access Object http://www.alfrek.net/blog/2008/07/dao-data-access-object/ http://www.alfrek.net/blog/2008/07/dao-data-access-object/#comments Tue, 08 Jul 2008 00:05:38 +0000 alfredojv http://www.alfrek.net/blog/?p=460 La mayorí­a de aplicaciones requieren de interacción con una base de datos, ya sea del tipo relacional u orientada a objetos y en la mayorí­a de los casos la persistencia de datos está mezclada con la lógica del negocio. Lo que supone un problema a la hora de querer cambiar el motor de base de datos.

Para entenderlo mejor formularemos un ejemplo de la vida real.

Imaginemos que estamos desarrollando una aplicación en la empresa donde trabajamos y estamos utilizando MySQL como motor de base de datos. Estamos en la fase de pruebas (ya a punto de publicar el producto final), y por alguna extraña razón a tu jefe se le ocurre que mejor deberí­amos usar Oracle, por que se lo recomendaron, piensa que es mejor, etc.

Que pasa si tenemos todo mezclado (lógica del negocio, métodos de acceso a datos, etc), se convierte en una tremenda pesadilla.

Para nuestra suerte existe el patrón de diseño Data Access Object (DAO), que se encarga de encapsular la interacción de una aplicación con la base de datos.

¿Como funciona?

DAO encapsula el acceso a la base de datos, de esta manera cuando la capa de lógica de negocio necesite interactuar con la base de datos, ésta utilizará los métodos ofrecidos por DAO. Generalmente la clase de operaciones que ofrece la capa de datos se le conoce como CRUD (Create, Read, Update y Delete).

Cuando la capa de negocios necesite almacenar datos (por ejemplo) solo tendrá que hacer referencia al método correspondiente para insertar los datos de la clase DAO, de esta manera si en algún momento se llegara a optar por usar otro motor de búsquedas, la capa del negocio no se debe preocupar ya que sólo bastará con actualizar la capa de datos. Si hablamos de patrones algunos detectarán por aquí­ que se están delegando responsabilidades, una buena práctica de la orientación a objetos.

De hecho el método de persistencia no debe de interesarle a la capa de negocios, es decir, a él no le importa si los datos se guardan en una tabla MySQL, XML, Texto plano o se imprime, de esto se encarga DAO.

Por cada tabla de una base de datos relacional existirá un DAO. Esto consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan las 4 funciones básicas (también conocidas como métodos CRUD).

Una vez entendido el funcionamiento de DAO, es conveniente explicar un nuevo término que nos será de ayuda para completar la implementación de nuestra capa de persistencia. Se trata de los DTO’s (Data Transfer IObject), los cuáles son utilizados por DAO para transportar los datos desde la base de datos hasta la capa de lógica de negocio o vice versa.

En pocas palabras un DTO es un objeto que en su interior tiene como atributos los mismos atributos del modelo, con sus correspondientes accessors (Setters y Getters).

dao-diagram.png

Diagrama DAO

Ahora veamos un ejemplo

Tenemos una aplicación que entre una de sus tantas funciones es controlar los datos de clientes, y queremos usar DAO para el manejo de la persistencia de dicha aplicación.
Primero que nada de define el modelo 8en este caso de clientes), para después partir con la codificación de los respectivos DTO y DAO.

DTO

Class ClientesDTO
{
      private $id;
      prí­vate $nombre;
      prí­vate $direccion;

      public static function getID( )
      {
          return $this->id;
      }

      public static function getName( )
      {
          return $this->nombre;
      }

      public static function getAddress( )
      {
          return $this->direccion;
      }

      /* Setters */
      Public static function setID( $id )
      {
          $this->id = $id;
      }
      Public static function setName( $name )
      {
          $this->nombre = $name;
      }
      Public static function setAddress( $address )
      {
          $this->direccion = $address;
      }
}

DAO

class clientesDAO
{
     public static function create( $dto )
     {
          /* implementación para la creación de un nuevo registro */
     }

      /* aqui van los demás metodos CRUD */
}

Por obvias razones no escribí­ todo el código necesario ya que este artí­culo es meramente informativo, pero pienso que es explicito el ejemplo para comprender el uso del patrón DAO.
En la próxima entrega les mostraré un ejemplo más real, utilizando una mezcla de patrones, como el DAO, Singleton, Factory y Faí§ade.

]]> http://www.alfrek.net/blog/2008/07/dao-data-access-object/feed/ 1 Patrones de Arquitectura: Presentacion-Abstraccion-Control (PAC) http://www.alfrek.net/blog/2008/05/patrones-pac/ http://www.alfrek.net/blog/2008/05/patrones-pac/#comments Tue, 27 May 2008 18:42:11 +0000 alfredojv http://www.alfrek.net/blog/?p=370 Es un modelo de arquitectura de software, algo similar al modelo-vista-controlador (MVC). PAC se utiliza como una estructura jerárquica de los agentes, cada uno de ellos consistente en una trí­ada de presentación, la abstracción y el control de partes. Los agentes (o trí­adas) se comunican entre sí­ sólo a través del control de parte de cada trí­ada. También difiere de MVC en que dentro de cada trí­ada, se aí­sla por completo la presentación (vista en MVC) y la abstracción (modelo en MVC), Este ofrece separar el modelo y la vista, lo cuál, da al usuario una experiencia de usuario por los cortos periodos, de cómo la interfaz (presentación) puede ser mostrada antes que la abstracción este completamente inicializada.

El control es algo similar al Controlador en la arquitectura MVC. Este procesa eventos externos y actualiza el modelo. También se actualiza directamente la parte de presentación. Sin embargo, es diferente del controlador en MVC en la medida en que éste pasa los cambios que se están realizando a su componente padre.

La Abstracción contiene los datos, al igual que en MVC. Sin embargo, puede ser sólo una parte de la estructura de datos completa de la aplicación, y no desempeñar un papel activo en la notificación de cambios.

La presentación es exactamente igual que la vista en el MVC. Muestra la información desde la abstracción.

Como funciona

El control padre crea los elementos de su hijo PAC, ya sea en el arranque del programa, o dinámicamente en tiempo de ejecución.
Cuando el control de un PAC recibe un evento de usuario (1), este debe actualizar su presentación (2a) y/o su abstracción (2b). A continuación, se enví­a un evento de cambio a su padre (3). El padre actualiza sus hijos (pero no al nodo donde surgió el cambio) (5), por lo que todos actualizan su Presentación (6a) y/o abstracción (6b). Después que los nodos han sido actualizados, el padre se actualiza (7). Esto termina cuando todos los elementos PAC necesarios han sido actualizados.

Los hijos y padres pueden enviar eventos muy concretos para actualizar a sus vecinos. De esta forma, los elementos PAC podrán decidir la extensión del efecto del cambio. Pequeños cambios no tienen por qué ser propagados a través de toda la jerarquí­a.

Problemas

Las actuales herramientas de programación visual tienen algo relacionado con esta arquitectura, pero tienen todo tipo de peculiaridades y excepciones. Así­ que se puede tratar de reconocer la arquitectura en herramientas visuales, pero no son tan exactos. Además, la mayorí­a de herramientas dicen basarse en la arquitectura MVC, lo que tampoco es completamente cierto.

Técnicas de implementación

El Control es modelado por el patrón de diseño Mediator.
La presentación es modelada por el patrón de diseño Strategy.

Start Slide Show with PicLens Lite PicLens]]> http://www.alfrek.net/blog/2008/05/patrones-pac/feed/ 0 Desarrollo Web en Tres Capas http://www.alfrek.net/blog/2007/07/desarrollo-web-en-tres-capas/ http://www.alfrek.net/blog/2007/07/desarrollo-web-en-tres-capas/#comments Tue, 31 Jul 2007 03:31:13 +0000 alfredojv http://www.alfrek.net/blog/2007/07/30/desarrollo-web-en-tres-capas/

“Divide et vinces”: Divide y Vencerás
Julio Cesar

Muchos diseñadores web están acostumbrados a tener las etiquetas HTML, junto con las reglas CSS y las funciones JavaScript. Para los que se pregunten ¿Y eso que tiene de malo? Este método no es de lo mas eficiente, ya que tienes una ensalada de lenguajes, esto hace que a la hora de querer hacer una revisión te pierdas entre tanto jeroglí­fico; por otro lado si tienes todo en un solo archivo la carga de la página se pone algo lenta ya que para el navegador es mas pesado cargar un archivo de muchos Bytes.
Hace tiempo hable sobre los Patrones de diseño, pero olvide mencionar que también existen los Anti-Patrones los cuales describen las malas conductas que no debe de tomar nunca un desarrollador, a continuación les pongo la descripción del antipatron que les estoy mencionando.
Código espagueti (spaghetti code): Construir sistemas cuya estructura es dificilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.

Mantener todo separado

Es sabido que las páginas Web se dividen 3 partes fundamentales:

  • Contenido: Define el contenido del sitio.
  • Presentación: Define el aspecto visual del sitio.
  • Comportamiento: Define las acciones del sitio.

Este método es llamado “Separación de preocupaciones”.

Entender e implementar éste método lleva tiempo y se necesita un poco de disciplina, pero una vez que hallan comprendido los beneficios de mantener todo separado tratarán de siempre hacerlo de esta manera.

Tres Capas

Mantener diferentes tipos de códigos lo mas separado posible es una buena práctica en cualquier tipo de programación. Facilita el re-uso de código, reduce notablemente la duplicidad de código y por último hace que la búsqueda y corrección de problemas sea mas fácil en un futuro.

Cuando esta practica es usada en la Web te permite conocer las diferentes maneras en las que los usuarios acceden a tu contenido, ya sea directamente, o víƒí­a algún lector de Feeds (Si ofreces RSS o algún otro formato parecido).

La clave para tener al mayor numero de visitantes es pensar en la Web como Tres capas.

A la hora de construir un sitio, debes de tomar en cuenta estas tres capas:
1. Empezamos produciendo el contenido en formato HTML. Esta es la base de todo.
2. Después agregamos un poco de CSS para darle un aspecto visual mas atractivo.
3. Finalmente, podemos agregarle JavaScript, PHP, o cualquier otro lenguaje para darle dinamismo al Sitio.

Si mantenemos el código HTML, CSS y JavaScript separados, veremos que nuestro sitio será legible para tantos navegadores capaces de usar CSS y JavaScript o para los que no tienen estas caracterí­sticas.

HTML para contenido

Todo lo necesario para leer el contenido de una pagina Web radica en el HTML. Algo que se debe de tomar en cuenta siempre es el principio K.I.S.S (Keep It Simple, Stupid). “Mantenlo simple, estupido“ por sus siglas en inglés.
El mezclar aspectos presentacionales con contenido y/o aspectos de comportamiento son detalles que traen problemas futuros en el desarrollo del Sitio.

¿HTML Semántico o No?

El usar etiquetas HTML para aspectos visuales se le denomina HTML no-semántico, es decir, el uso de etiquetas

<b>, <i>, <u>, <font>, etc..
<p><a xhref=”Desc.html”><font color=”red”>20% de descuento</font></a> todo el mes</p>

Esto puede tomar forma usando atributos CSS:

<p> <a zhref="Desc.html" class="red">20% de descuento</a> todo el mes</p>

Si piensas que esta forma está bien, este artí­culo te ayudará a tomar el camino del bien. Si en un futuro decides que quieres el link Amarillo, tendrí­as que cambiar el CSS, y cambiar la referencia a la clase, o dejar la referencia como “red”, cuando en realidad es amarillo.

Mas que mostrar información presentacional en tu código HTML, deberí­as enfocarte a qué es lo que realmente quieres, por ejemplo, en nuestro caso lo que deseamos es enfatizar el 20% de descuento, entonces, ¿Por qué no usar la etiqueta < em > < / em >? Que precisamente es para eso.

<p><em><a href="Desc.html">20% de descuento</a></em> todo el mes</p>

¿El link es una advertencia?, entonces usemos mejor una clase CSS que referencie a la llamada de advertencia.

<p> <a href="Desc.html" class="advert">20% de descuento</a> todo el mes</p><

Esta serí­a la mejor forma de usar HTML semántico, es decir, usar solamente las etiquetas para marcar contenido, no para especificar el aspecto visual del mismo.

Algunos diseñadores Web caen en el error de que las etiquetas < h1 > son presentacionales, y tratan de evitarlas usando HTML:

<p class="titulo"> Desarrollo Web en Tres Capas </p>

El hecho de que una porción de texto sea un titular es parte del contenido, viéndose reflejado en en el HTML, esta etiqueta es correcta:

<h1>Desarrollo Web en Tres Capas</h1>

Esta forma de usar el HTML, de manera que solo se utilicen etiquetas para el contenido es llamada por los estándares Web HTML semántico.

Utilizar el marcado semántico permite que tu código sean documentos totalmente legibles, personas que por cualquier razón, no pueden leer el sitio de manera normal, el HTML serí­a totalmente comprensible por las personas, ya que estás usando meramente etiquetas que describen los significados del contenido.

Lo mejor de todo, sin embargo, es que el marcado semántico te permite aplicar nuevos estilos (presentaciíƒón) o interactividad (comportamiento) sin tener que hacer muchos, o en algunos casos ningún cambio al código HTML.

CSS para Presentación

Obviamente los aspectos relacionados con la forma visual del contenido radica en las reglas CSS usadas para el Sitio.

Con todo el trabajo hecho, manteniendo el código HTML con marcado semántico, la tarea de darle vida al contenido, se convierte en algo mas sencillo, aplicando estilos CSS.

Como probablemente sabrás los estilos CSS, pueden ser aplicados de 3 formas distintas:

  • Estilos en linea
  • Estilos Embebidos
  • Estilos Externos

Los estilos externos son realmente el camino a seguir a la hora de diseñar una Pagina Web, debido a que te permite compartir esos estilos a múltiples documentos, reduciendo la duplicidad de código, y la cantidad de descarga de código necesario por el navegador, y por último a la hora de querer cambiar el aspecto gráfico del Sitio, no necesitarás meter las manos al código HTML.

JavaScript para comportamientos

Al igual que CSS, es posible agregar JavaScript de diferentes formas, pero este documento pretende utilizar la forma externa de hacerlo.

<script type="text/javascript" src="script.js"></script><

Escribir JavaScript que aumente la usabilidad sin estorbar al Sitio, sin la necesidad de bloquear aquellos usuarios que tengan deshabilitado el JavaScript en sus navegadores, y sin interferir en otros Scripts que deban ser aplicados a la página, es llamado JavaScript no obstrusivo.

Artí­Â­culo original | SitePoint Simple Javascript
Analizado, Sintetizado y traducido por Alfredo Juárez.
Se trata de un pequeño resumen del primer capitulo de este libro, la verdad es que es totalmente recomendable si les interesa aprender JavaScript para añadirles dinamismo a los desarrollos Webs.

Start Slide Show with PicLens Lite PicLens]]> http://www.alfrek.net/blog/2007/07/desarrollo-web-en-tres-capas/feed/ 3 Patrones de Diseño (Design Patterns) http://www.alfrek.net/blog/2007/07/patrones-de-diseno-design-patterns/ http://www.alfrek.net/blog/2007/07/patrones-de-diseno-design-patterns/#comments Thu, 05 Jul 2007 01:18:12 +0000 alfredojv http://www.alfrek.net/blog/?p=10

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de la solución al problema, de forma que puede utilizarse un millón de veces sin tener que hacer dos veces lo mismo.”

Christopher Alexander

Como habí­a quedado esta es la segunda entrega sobre arquitectura de software, esta vez enfocada a los patrones de diseño los cuales describen un problema que ocurre en repetidas ocasiones en algún contexto determinado de desarrollo de software, y entregan una buena solución. Esto ayuda a diseñar correctamente en menos tiempo, evitando los errores que tan comúnmente se atribuyen a la etapa del diseño de software.

Un patrón de diseño es una solución a un problema que ya ha sido resuelto satisfactoriamente en ocasiones anteriores y a su vez puede ser reusable (aplicable a diferentes problemas de diseño en distintas circunstancias).
Siendo estos la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Al dí­a de hoy es recomendable realizar un análisis, diseño e implementación orientado a objetos, a no ser que exista una excepción requerida por las circunstancias de la aplicación o campo en el que nos movemos.
Para la parte de análisis y diseño se recomienda utilizar el Lenguaje de Modelado Unificado (UML por sus siglas en ingles).

Análisis Orientado a Objetos

En el análisis se estudia el dominio del problema para construir un modelo del mundo real utilizando objetos. Se investiga para hacer una descripción del problema y obtener todos los requerimientos necesarios.
Se realiza una investigación del problema.
Durante el Análisis, se enfatiza en encontrar y describir los objetos (o conceptos) en el dominio del problema.
Por ejemplo: conceptos en un sistema de información para una librera incluyen Libros, Librerí­a.
El í‰nfasis es en la investigación del problema y sus requisitos (mas que en una solución)
Se resume en: Haz lo correcto (Do the Right Thing)

Diseño Orientado a Objetos

Se enfatiza una solución conceptual que satisface los requerimientos.
Se necesita definir objetos software y como colaboran entre si para satisfacer los requerimientos.
Por ejemplo: en el sistema de información de una librerí­a el objeto software “libro” deberí­a tener un atributo “titulo” y un método obtenerCapitulo();
Diseños son implementados en un lenguaje de programación
Se resume en; Haz las cosas bien. (Do the thing right)
A pesar del esfuerzo realizado en las etapas anteriores surgen problemas debido al uso inapropiado de la orientación a objetos, una muy común es el mal empleo de la encapsulación.

Otro de los problemas fundamentales es el vacio que existe entre el análisis, diseño e implementación, que hace que el programador tenga la necesidad de tomar decisiones de diseño.

Para solventar dichos problemas se produce un nuevo enfoque: el diseño con patrones. La idea fue propuesta inicialmente por el arquitecto Christopher Alexander, que aplica el concepto a la construcción de edificios en menos tiempo con la publicación de su libro “The Ti­meless Way of Building” en el año de 1979.
No obstante, no fue hasta principios de los 90í¢â‚¬â„¢s cuando los patrones de diseño tuvieron gran í‰xito en el mundo de la informática a partir de la publicación del libro Design Patterns escrito por el GoF (Gang of Four) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que recogí­an 23 patrones de diseño comunes.

Objetivos de los patrones
Los patrones de diseño pretenden:

  • Proporcionar catálogos de elementos reusables en el diseño de sistemas de 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 el conocimiento ya existente.
  • Sin embargo, no se pretende obligar a utilizar los patrones de diseño siempre, solo en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abuzar o forzar el uso de los patrones puede ser un error.

Clasificación de los patrones
Según la escala o nivel de abstracción:

  • Patrones arquitecturales: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas software.
  • Patrones de Diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software.
  • Idiomas: Patrones bajo nivel especí­ficos para un lenguaje de programación o entorno concreto.

Según el propósito: Qué hace el patrón.

  • Patrones de Creación: para creación de instancias.
  • Patrones estructurales: relaciones entre clases, combinación y formación de estructuras mayores.
  • Patrones de Comportamiento: Interacción y cooperación entre clases.

Patrones Creacionales

  • Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí­Â­ y haciendo transparente el tipo de familia concreta que se esté usando.
  • Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un íšnico punto.
  • Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuí­stica para elegir el subtipo que crear.
  • Prototype (Prototipo): Crea nuevos objetos cloníndolos de una instancia ya existente.
  • Singleton (Instancia íšnica): Garantiza la existencia de una íšnica instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.

Patrones Estructurales

  • Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podrá utilizarla.
  • Bridge (Puente): Desacopla una abstracción de su implementación.
  • Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
  • Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
  • Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
  • Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
  • Proxy: Mantiene un representante de un objeto.

Patrones de Comportamiento

  • Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lí­nea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
  • Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
  • Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así­Â­ como las herramientas necesarias para interpretarlo.
  • Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
  • Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
  • Memento (Recuerdo): Permite volver a estados anteriores del sistema.
  • Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de í‰l.
  • State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
  • Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
  • Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
  • Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquí­a de clases sin modificar las clases sobre las que opera.

Conclusiones

La idea de los patrones ha adquirido gran popularidad. En el ámbito de la ingenierí­a de software; se están desarrollando muchos proyectos de investigación al respecto. No sólo se están aplicando en los llamados patrones de diseño, sino que la idea esta transportándose a otras actividades del desarrollo de software.

El concepto de patrón tiene carácter general y por consiguiente es aplicable a un sin número de situaciones de diferentes tipo, estilo, entorno, etc. En lo referente al software, la aplicación de los patrones esta siendo utilizada con éxito en muchos ámbitos de la ingenierí­a de software. En definitiva está mejorando las prácticas en el desarrollo de sistemas de información.

Donde exista la posibilidad de aplicación del criterio profesional experimentado, a un problema recurrente, la idea de patrones de Alexander podrá usarse para reutilizar y transmitir dichas experiencias a profesionales menos experimentados.

Por lo tanto podemos resumir un patrón con los siguientes puntos:

  • Un Patrón de Diseño, es un conjunto de información que describe una solución recurrente a un problema de diseño no trivial.
  • La efectividad de esta solución ha debido ser probada muchas veces por profesionales expertos dentro de un contexto determinado en situaciones anteriores.
  • Esta solución debe ser reutilizable, para problemas de diseño similares en distintas circunstancias.
  • Esta descripción de un patrón debe ser lo suficientemente explí­cita para que pueda ser transmitida a profesionales no expertos”.

Bibliografí­a

Design Patterns. Elements of Reusable Object-Oriented Software – Gamma, Helm, Johnson, Vlissides – Addison Wesley
UML y Patrones. Introducción al análisis y diseño orientado a objetos – Larman – Prentice Hall
Patrones de diseño – Wikipedia

]]> http://www.alfrek.net/blog/2007/07/patrones-de-diseno-design-patterns/feed/ 2