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 – Una librería que habla YAML
Symfony YAML es una libreria PHP que convierte cadenas YAML a arreglos PHP y viceversa.
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 – 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
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.
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.
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).
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.
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.
“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.
Continuar leyendo esta entrada »
Start Slide Show with PicLens Lite 
Recent Comments Gravatars
alfredojv on DISEÑO DE INTERFACES DE USUARIO EN APLICACIONES WEB MODERNAS
SirphatOn on DISEÑO DE INTERFACES DE USUARIO EN APLICACIONES WEB MODERNAS
osvmza on [Tips] función para obtener todos los elementos de cierto tipo en javascript
Alfredo Juarez is Digg proof thanks to caching by WP Super Cache
