Archive for the 'Programación' Category
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 manera simple de manejar un error es usando die( ) cuando éste ocurre, sin embargo, a esto se le conoce como el suicidio del software. Aunque Martin Fowler nos dice que: “Si el costo de que el programa truene es pequeño y el usuario es tolerante así está bien”.
En PHP 5, como en muchos otros lenguajes, tenemos una alternativa al suicidio: Lanzando una excepción. Si no manejamos la excepción con un catch el sistema terminará el programa de la misma manera que die( ), agregándole un trazado de la pila (stack trace). Pero si en un futuro decidieramos manejar cierto error, de esta manera ya sería más sencillo.
¿Como funcionan?
El lenguaje de programaciónsabe que exception es una manera de comunicar un error o condiciones de excepción entre diferentes partes del programa. Por ejemplo, imaginemos que tenemos un método para conectar con una base de datos MySQL.
$db = new DBM;
if ( !$db->connect( ) )
die("Error: no se puede conectar");
else
{
// .....
// --------->
// .....
}Esta es la versión suicida usando die( ), ahora veamos la versión utilizando el manejo de excepciones:
$db = new DBM;
if ( !$db->connect( ) )
{
throw new Exception(
"ERROR: no se ha podido conectar");
}
else
{
// .....
// --------->
// .....
}Si no hacemos nada para cachar la excepción, esto tiene el mismo efecto que die( ): Para la aplicación, además, este método hace una cosa adicional, imprime un stack trace, la cual puede ser muy usable para el debugging. Puedes obtener un stack trace sin usar excepciones usando las funciones debug_backtrace( ) y debug_print_backtrace( ). Pero lanzando una excepción es aún más sencillo de hacerlo.
Fatal error: Uncaught exception 'Exception' with message
'Error: no se ha podido conectar' in /path/exception.php:6
Stack trace:
#0 /path/exception.php(6): DBM::connect()
#1 /path/exception.php(12): DBM->connect()
#2 {main}
thrown in /path/exception.php on line 6
Si no queremos que los usuarios vean estos errores técnicos (por cierto no deberíamos por cuestiones de seguridad), estamos en una mejor posición por haber usado excepciones que usar die( ). Si hemos usado die( ) en muchos lugares, tenemos que encontrar todas las ocurrencias y cambios en cada una. Si usamos excepciones, todo lo que necesitamos es cacharlas en algún lugar conveniente, por ejemplo, pudieramos registrar el mensaje y redireccionar al usuario a una pagina de error.
$db = new DBM;
try
{
$db->connect( );
}
catch (Exception $e)
{
$logger->log($e->getMessage());
header("Location: error.php");
}Como podrán ver el manejo de excepciones es algo imprescindible en el desarrollo de aplicaciones, ya que manejas de una manera más elegante los errores que surjan dentro de la aplicación. En próximas entregas les mostraré más ejemplos y profundizaré en el manejo de excepciones en PHP.
Se trata de improvisar el diseño de un código existente. No estás agregando nuevas características, solo estás moviendo, separando, combinando, eliminando y renombrando. Es una manera de mantener el código flexible para que éste siempre sea sencillo de mantener y agregar nuevas características, aún y cuando crezca en complejidad.
La refactorización reestructura la parte interna del código fuente sin alterar su comportamiento externo. Mejor conocido como el proceso de limpiar el código, en ingeniería de software se usa a menudo como parte del desarrollo de software, de esta manera los desarrolladores alternan la inserción de nuevas funcionalidades y casos de prueba con la refactorización del código para mejorar su consistencia interna y su claridad.
La refactorización es la parte del mantenimiento del código donde no se arregla errores ni se añade funcionalidad. El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño, así como eliminar código muerto, para facilitar el mantenimiento en el futuro.
Sin la refactorización, es fácil de entrar en una vía de un solo camino que guía directamente a la muerte del programa. Entre más pobre sea la estructura del código, más tendencias tienes a llegar a lo que se le llama “programación aproximada”, es decir, se refiere al hecho que si no entiendes tu propio código, puedes seguir metiéndole cosas y moviéndole hasta que encuentres algo que funcione. Desafortunadamente, programación aproximada embrolla el código aún más y hace el trabajo más duras la próxima vez. Frecuentemente, terminarás con la necesidad de re-implementarlo todo.
Hay muchas maneras conocidas y desconocidas de refactorización. Martin Fowler y otros nos han hecho el favor de catalogar un numero de técnicas de refactorización. El libro de Fowler Refactoring tiene instrucciones específicas, paso a paso de cómo hacer cada uno de ellos.
Pruebas automáticas son la clave de la refactorización. Ellos hacen posible probar el código entre cada paso pequeño en la refactorización. Hacer este tipo de pruebas repetidas manualmente puede ser por mucho una tarea que consume mucho tiempo. Así que, si no tienes pruebas automáticas, tu probarás el código hasta el final de la refactorización. Cuando finalmente empieces a probar, pudieras encontrar muchos bugs.
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 mezlcado (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.
Estas pueden ser buenas y malas noticias, ya que por un lado los desarrolladores ya no podemos poner el pretexto de no hacer webs en flash por que son anti-buscadores, es decir, los bsucadores no pueden indexar su contenido por estar hechas en flash.
Por otro lado los clientes se verán beneficiados, ya que ahora podrán tener sus webs llenas de vida (a los que les gustan las páginas en Flash).
Google y Adobe hicieron una alianza para que el buscador pudiera indexar el contenido de los flash. Siendo anunciado unos días atrás que Google ha desarrollado un algoritmo con el cuál será posible la indexación.
Ahora si que no hay pretextos, si un cliente lo quiere en flash….
Links
Según un informe realizado por la consultora EvansData, quién realizó una encuesta se afirma que sólo un 8% desarrolla para Windows Vista, también se dice que para el 2009 las cosas pueden mejorar, ya que se espera que aumente el número de desarrolladores interesados en Vista a un 24%.
¿Será acaso el principio del fin del gigante de la informática?, empezando a sufrir lo que sufría Linux en sus inicios, donde nadie se interesaba en desarrollar para ellos, que ahora se ve menos este problema.
¿Qué tendrá planeado el monstruo de los tentáculos para solventar este tremendo problema?. Si bien es cierto gran parte de los desarrolladores siguen en Windows XP, muchísimos han hecho su transición a OS X, y muy confirmado quedó en la pasada WWDC, quienes batieron el récord de asistentes dejando a muchos en la cola de espera, por falta de lugares.
Al leer esta noticia me surgen muchas preguntas, que en un futuro no muy lejano se irán contestando solas.
Una keynote muy monotemática, el iPhone se vio mencionado a lo largo de ésta. Acerca del Snow Leopard solo se mencionó que se iba a cubrir a lo largo de la semana pero no se especificó nada al respecto.
En resumen:
Se presentaron desarrolladores con ejemplos de aplicaciones para el iPhone, en donde se vieron juegos y aplicaciones médicas.
Después se presentó el rumoreado Mobile ME, el cuál es una renovación del ya enterrado .Mac. Que trae consigo mejoras muy notables.
- Hasta 20gb de almacenamiento
- Contactos
- Calendario
- Fotos
Por solo 99 dólares anuales.
Y luego siguió el tan esperado anuncio del iPhone 3G, ese que todo el mundo andaba diciendo y maldiciendo alrededor de la blogosfera, prensa escrita, televisión, etc.
Ahora por fin quedó confirmado la segunda generación del famoso iTelefonito, y lo que es mejor, con una contundente rebaja de precio, tal cómo lo dice la página de Apple: “El doble de rápido, a mitad de precio”
Como bien comentó Steve jobs, ahora estará disponible en muchos paises, que dicho sea de paso también incluye méxico, siendo telcel la operadora encargada de distribuirlo por estos rumbos.
El precio de inicio será de USD$199 para la versión de 8gb, y estará disponible desde el día 11 de julio de los corrientes. Solo falta esperar las sorpresas que nos tenga telcel. Así que hay que mantener la cartera guardada por el momento.
Si además de eso quieres conocer un poco de lo que poco se mencionó puedes ir a este link para leer el comunicado de prensa oficial. Y por si no sabes de que hablo me refiero al poco sonado Snow Leopard, el cual planean que esté disponible dentro de un año.
En unos cuantos minutos dará inicio la tan esperada keynote de Steve Jobs, en el marco de la WWDC’08, que dicho sea de paso por primera vez en la historia se vendieron todas las entradas del evento.
Como ya lo comenté por estos lares la lista de rumores es grande, y tenemos una tarjeta de bingo para ir pasando lista de los que se cumplan.
En esta ocasión no tuve la oportunidad de asistir, pero igual estaré pendiente de las cosas que sucedan.
si les interesa el tema, o quieren saber a primera hora las novedades presentadas por Steve Jobs, pueden seguir las coberturas en vivo que harán algunos blogs que les dejaré a continuación.
la foto que acompaña la entrada fue tomada prestada de gizmodo.
siendo sincero no se si tenga algo que ver, ni tampoco es algo relevante, pero bueno aquí se los dejo para los curiosos.
Via aNieto2k
Todo parece indicar que Google implementará un modelo parecido al App Store, que anunciara Apple en la pasada Keynote donde se presentó el iPhone SDK, el cuál consiste en una “tienda online” de aplicaciones para el dispositivo.
De momento la Android Store no ha sido oficialmente confirmada, pero las palabras del lider de proyecto Andy Rubin en la Google I/O conference dan algo de que hablar:
“Sería un gran beneficio para la comunidad Android de proporcionar un lugar donde la gente puede ir a la segura y sin peligro para descargar contenido y que un sistema de cobro se encargue de remunerar a los desarrolladores por sus esfuerzos … Nosotros no hemos hecho nuestro trabajo si no ofrecemos ayuda a los desarrolladores a la distribución de su trabajo.”
