Mostrando entradas con la etiqueta programacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta programacion. 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.

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.

sábado, 18 de octubre de 2014

Buenas tardes lectores, hoy les traigo otra entrada relacionada con el tema de los lenguajes de programación, java en android, ¿por qué lo eligieron?, empecé con las razones por las que uso php, luego hablé un poco de visual basic, y ahora hablaré sobre Java.


Hacía varios días que esta entrada estaba a la espera de ser redactada, y recién hoy que estaba husmeando un poco el framework de un amigo que realmente se ve muy muy prometedor, tengo que admitir que si su framework ve la luz mi publicación de los frameworks son una basura tendrá que ser retractada, analizando su código me surgieron algunas preguntas sobre como encararía ciertos aspectos, que para avisarles me dejó realmente satisfecho, al final de la charla surgió el gran dilema del a industria y quizá el soporte en el cual está apoyada esta entrada. ¿Mi código debe ser a prueba de idiotas, o para gente que tenga conciencia de lo que programa?

sábado, 11 de octubre de 2014

Buenas tardes lectores, el otro día estaba pensando en razón de (creo) una charla que tuve con un amigo y me cuestioné la utilidad de este patrón de diseño MVC, ya que resulta que suele ser el as bajo la manga de cualquier programador en php para decir que su código responde a un patrón que le asegura la robustez



Desde ya que decir que el patrón mvc asegura la robustez en un código es una falacia, mvc aplicado a la web es una total mentira y ahora explicaremos el porqué de esto.

jueves, 9 de octubre de 2014

Buenas tardes, los que me conocen y siguen el blog sabrán que rara vez publico código, pero hoy traigo un proyecto que me llevó bastante tiempo y me costó un poquito realizar y me gustaría compartir con ustedes.


El proyecto lo comencé, porque desde que hice las distintas versiones de mi bot de irc en php, siempre tuve la mala suerte de decidir crear nuevas clases una y otra vez para manipular los sockets ya que ninguna me convencía pero no deceaba perder demaciado tiempo en el desarrollo de una clase manipuladora de sockets siendo mi proyecto en realidad un bot para irc.

Subscribete al RSS Follow me on Twitter!