Mostrando entradas con la etiqueta diseño. Mostrar todas las entradas
Mostrando entradas con la etiqueta diseño. Mostrar todas las entradas

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.

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.

jueves, 26 de septiembre de 2013



Hola, buenas tardes, bienvenidos a otra publicación diaria de mi blog, la idea de ésta publicación es seguir el hilo de "Diseñando Software", en la publicación del día de hoy realizaré un resumen de los conceptos generales y de los diagramas que conforman UML.

Pero antes de comenzar y como siempre voy a comentarles...

viernes, 20 de septiembre de 2013

Buenas noches, hoy parece que voy a incumplir mi lema "una publicación por día" porque me surgió la necesidad de publicar una entrada referente al tema en cuestión. Mirando webs descubrí una "batalla" entre usuarios de quien tenía razón sobre si escribir HTML es programar o no, y teniendo en cuenta que siempre salta a la luz la pelea por este tema decidí hacer una entrada y expresar ALGUNOS de mis argumentos por los cuales explico que escribir HTML no es programar, aclaro que algunos, ya que si escribiera todos, no terminaría nunca con mi entrada.

pero antes chicos les dejo la advertencia de siempre...

Subscribete al RSS Follow me on Twitter!