Mostrando entradas con la etiqueta patron. Mostrar todas las entradas
Mostrando entradas con la etiqueta patron. Mostrar todas las entradas

miércoles, 4 de febrero de 2015

En la entrada de hoy hablaremos sobre el patrón creacional de diseño Prototype, en entradas anteriores podemos apreciar diferentes patrones, como Factory, ObjectPool, etc. puedes ver por supuesto la entrada introductoria al tema aquí, y puedes ver el listado de teoría donde hay una sección de patrones aquí.

El patrón prototype tiene como idea fundamental, la de crear objetos basandose en clonar objetos previamente creados, debe incluir en su abstracción la funcion clonadora, para que luego en cada caso particular se establezca las especificaciones de la clonación (esto es la funcion __clone).

Este patrón es de utilidad cuando se quiere separar la lógica de la creación de objetos de su futura implementación creando así una instancia inicial pasando por todo el proceso de la creación, para luego simplemente copiar esa instancia y manejarla sin pensar en como fué construida y no tener que pasar por dicho proceso de nuevo.

La instancia prototipo solo debe ser utilizada para ser clonada, y no debe ser utilizada con otro propósito, por evidentes razones.

dejo aquí un ejemplo de código de prototype en php:


un saludo para todos los lectores!

martes, 3 de febrero de 2015

Buenas tardes lectores, en esta entrada hablaremos sobre el patrón singleton, quizá sea uno de los patrones más conocidos al menos en lo que se refiere a php, en entradas anteriores hablamos sobre ObjectPool, sobre Factory, y hasta sobre Prototype, también pueden ver aquí la entrada inicial al tema. En particular también hay una entrada que referencia a Singleton pero como una queja al mal uso que le da la mayoría de la gente al menos en php.

La utilidad de singleton comienza cuando nosotros requerimos de una clase una única instancia y nada más que una, y que la creación de multiples instancias de una clase pueda traernos problemas ya que no fué diseñada para eso.

De modo que el patrón establece una forma de obtener una sola instancia de la clase en todo momento, y si se trata de obtener una nueva, Singleton devolverá la instancia que ya tenía.

Para tales efectos se construye un metodo constructor del objeto, éste tiene que ser estático, y también se crea una propiedad estática que almacenará la instancia para devolverla en futuras ocaciones, el constructor si se puede, debe ser transformado en privado (dependiendo del lenguaje), ya que no se debe permitir a la persona construir el objeto directamente, luego en el metodo estático de construcción del objeto creamos una instancia de la clase si es que no hay una guardada en la propiedad destinada para tal trabajo, y si la hay simplemente devolvemos la que ya teníamos almacenada.

Quien quiera obtener una instancia de esa clase debe llamar al constructor estático de singleton para que asegure que tendremos siempre la misma instancia.

Un ejemplo de singleton en php:


Ahora que vamos cerrando las entradas relacionadas con patrones creacionales, siempre hay que tener en cuenta si el patrón que aplicamos corresponde con la situación dada, ya que estos patrones si se los usa en cualquier situacion sin importar si aplican al problema o es un problema que no tiene relación, estaremos en algunos casos derrochando recursos, y en otros estaremos limitando la usabilidad de las clases. Siempre que apliques un patrón debes tener una razón.

Un saludo lectores y espero que les haya gustado esta entrada.

miércoles, 5 de noviembre de 2014

En entradas anteriores vimos Factory Method, y en esta entrada veremos Abstract Factory un patron creacional que amplía el rango de Factory Method. También vimos ObjectPool y una introducción a los patrones de diseño.

Recomiendo leer como minimo el Factory Method para que les sea más sencillo el Abstract Factory.

Si vemos la explicación del Factory Method notaremos que es útil para la creación de objetos de clases subtipos de una en particular, pero si quicieramos tener más de un tipo de clase principal, deberíamos hacer uso de un patrón que lo soporte.

Podemos ver en wikipedia como se explica que si nosotros trabajaramos con botones, dependiendo de la plataforma tendríamos un gran tipo de objeto para botones en linux y uno para botones en windows, si nosotros quicieramos crear objetos de ambos tipos con un factory necesitaríamos utilizar este patrón.

La solución para este problema es simple, si vemos el código de ejemplo de la publicación de Factory Method veremos que la factoría nos permitía crear objetos del tipo de EjemploConcreto, ahora si quicieramos además poder crear de tipode clases OtroEjemploConcreto, bastaría con crear métodos factory para cada clase en particular.

podemos ver el código aquí:

http://pastebin.com/V0HS6fU2

y un diagrama del Abstract Factory extraído de wikipedia:


Un saludo para todos! espero que les haya gustado la entrada y nos veremos la próxima!

domingo, 2 de noviembre de 2014

En una de las entradas anteriores hablamos sobre Patrones de diseño, realizamos una introducción simple y ahora hablaremos sobre el Factory Method, un patrón creacional.

Sugiero ver el patrón anterior, el ObjectPool que incluye una explicación de los patrones creacionales y su razón de ser.

El factory method es un patrón de diseño creado para resolver el problema que sucita a la hora de crear instancias de muchos subtipos de clases que tengan particularidades, los detalles que incluyen pueden resultar innecesarios para el cliente que implemente dichas clases, de modo que se engloba el proceso de construir las instancias en una clase constructora.

Pueden ver un ejemplo del factory method en php en el siguiente enlace:


Espero que les haya gustado la idea, pd: la imagen fue sacada de wikipedia.

miércoles, 29 de octubre de 2014

En esta entrada hablaremos sobre el patrón creacional Object Pool, recordemos que en la entrada anterior de este hilo vimos una introducción a los patrones en general, pueden apreciarla aquí (además de ver un índice de patrones)

En primera instancia hablaremos sobre los patrones creacionales, son aquellos patrones diseñados para solventar problemas enlazados a la creación o instanciación de objetos.

El patrón object pool está diseñado para almacenar instancias de los objetos, un cliente del Object Pool, solicita un objeto, el Object Pool lo devuelve, el cliente lo utiliza, y luego se lo devuelve al Object Pool, de modo que éste lo almacena y espera su próxima solicitud, cuando le solicitan el objeto nuevamente, el Object Pool lo devuelve y así continúa el ciclo, la idea de este patrón es reciclar un objeto. Como apreciará la utilización de este patrón implica que un objeto no se construye y destruye varias veces, sino que se recicla.

Pero hay que ser muy conciente de su funcionamiento, ya que es únicamente útil en situaciones donde el costo de crear una instancia sea relativamente alto, a diferencia del costo de mantenerla almacenada, de modo que solo es útil en ocaciones tales como clases de sockets o de recursos gráficos.

Hay situaciones en donde el costo de utilizar este patrón es mayor al costo de no utilizarlo, y hay situaciones en las que es al reves.

Un ejemplo de object pool en php:


Saludos, espero les haya gustado la entrada y sigan pendientes de las siguientes entradas.

sábado, 25 de octubre de 2014

En esta entrada comenzaremos el hilo de Patrones de Diseño, y comenzaremos hablando sobre una introducción a patrones de diseño, en entradas anteriores hablamos sobre el mal uso que se le da a singleton, y en esta entrada hablaremos sobre los distintos patrones.

El arquitecto Chritopher Alexander dijo en su libro:

"Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, además incluye una solución para ese problema, de tal manera que usted pueda usar esa solución un millón de veces y más".
Si bien Christopher hablaba de patrones de edificios, no se aleja mucho de la idea de patrones en la industria del software, cuando un problema aparece una cantidad de veces bastante importante, se define un patrón del problema, y se busca una solución que aplique a todos los casos y casos futuros.

Como anuncia wikipedia, un patrón para serlo debe cumplir ciertas características, una de ellas es que debe comprobar su efectividad resolviendo el mismo problema en situaciones anteriores, y otra es la re-usabilidad, que significa que el patrón debe ser aplicado en futuras ocasiones donde el contexto varíe.

Por lo general un patrón está compuesto por cuatro partes:

El nombre: que nos sirve como descripción del problema y la solución que abarca dicho patrón.
El problema: el problema que trata de resolver y para el que fue diseñada la solución (por este motivo mi publicación en queja de la utilización del patrón mvc en la web)
La solución: además de ser la solución al problema, hay que aclarar que no es específica a una situación en concreto, recordemos que los patrones tratan de resolver problemas que ocurran varias veces en situaciones diferentes, funciona prácticamente como una plantilla.
La consecuencia: nos referimos con esto, a los resultados de aplicar el patrón y a los compromisos que conlleva la utilización de dicho patrón.

Los patrones que serán abarcados en las futuras entradas serán los siguientes:

Patrones Creacionales:
Object Pool
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Model-View-Controller

Patrones Estructurales
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Patrones de comportamiento
Chain of Responsibility
Command
Interpreter
Iterator
Memento
Observer
State
Strategy
Template Method
Visitor

Espero que les haya gustado la entrada, y espero verlos leyendo sobre cada patrón a medida que los publique.
Subscribete al RSS Follow me on Twitter!