• Scrum y XP desde las trincheras.
• Kanban y Scrum - Obteniendo lo mejor de ambos.

Me dispongo a iniciarme en el mundo de TDD. Para los que no sepáis qué es TDD, se trata de una metodología de desarrollo basada en pruebas: "Test Driven Development" (Desarrollo guiado por pruebas).

Hace varios días que comencé a escribir pruebas unitarias y de integración en mis aplicaciones Symfony y una vez que me noto con soltura y empiezo a cogerle el ritmo (y el gustillo) he decidido que es un buen momento para iniciarme en TDD. Para ello he elegido un libro escrito por Carlos Ble: Diseño Ágil con TDD.

Aclarando conceptos iniciales:

• Prueba unitaria: se encarga de testear un caso concreto (atómico). Por ejemplo para testear la operación suma en una calculadora. Este tipo de pruebas no pueden modificar el estado del sistema, es decir, no pueden ejecutar operaciones sobre base de datos, enviar emails, etc.
• Pruebas de integración: al igual que las pruebas unitarias, testean un caso atómico de una clase pero con la diferencia de que si pueden ejecutar operaciones sobre el sistema. Para ello se usa un entorno de test (por ejemplo se crear una BBDD con sufijo "_test" y se prueba sobre ella). En cada prueba de integración se ejecutan unos métodos especiales que preparan el sistema, normalmente starUp y tearDown, el primero prepara el sistema (ejemplo: introduce datos en la BBDD de tests) y el segundo devuelve el sistema al estado inicial (ejemplo: borra los datos).
• Pruebas funcionales: son las pruebas que se encargan de reproducir el comportamiento de la aplicación a nivel usuario (Ejemplo: ejecutar un login en la web).

Esto es todo por el momento. Prometo postear con lo que vaya aprendiendo sobre TDD.

Algunos enlaces de interés:

TDD en la Wikipedia.

El blog de Carlos Ble.

Diseño ágil con TDD.

Hace poco comencé a usar esta opción que nos brinda a todos el ORM Doctrine. Tras dos o tres task lanzados, ya me enteraba de como funciona, es más, empecé a cogerle el gusto...

La idea parte teniendo un schema.yml inicial, una BBDD en el servidor y la necesidad de incorporar cambios en ambos. El uso es mucho más extenso, pero me voy a centrar en los siguiente:

Teniendo el schema.yml

# config/doctrine/schema.yml

Category:
    columns:
        id:
            type: integer(11)
            notnull: true
            autoincrement: true
            primary: true
            unsigned: true
        name:
            type: string(255)

Y la BBDD en el servidor exactamente tal y como se declara en el schema.

Se necesita aplicar un cambio en la BBDD (añadir/eliminar columna, modificar una relación, etc.).

# config/doctrine/schema.yml

Category:
    columns:
        id:
            type: integer(11)
            notnull: true
            autoincrement: true
            primary: true
            unsigned: true
        name:
            type: string(255)
Item:
    columns:
        id:
            type: integer(11)
            notnull: true
            autoincrement: true
            primary: true
            unsigned: true
        category_id:
            type: integer(11)
            notnull: true
            unsigned: true
        name:
            type: string(255)
    relations:
        Category:
            local: category_id
            foreign: id
            type: one
            foreignAlias: Items

Cómo hacemos esto?

1. Modificar el schema.yml para aplicar el cambio.

2. Lanzar el task $ php symfony doctrine:generate-migrations-diff. Esto crea una estructura de ficheros en el directorio lib/ del proyecto:

• lib/migration/doctrine (Directorio que contiene los cambios a aplicar)
  
• x_versionN.php (Archivo que contiene los cambios para pasar a la versión N)
• Tabla migration_version en el servidor, que almacena la versión actual.

// lib/migration/doctrine/1283537548_version1.php

class Version1 extends Doctrine_Migration_Base
{
    public function up()
    {
        $this->createTable('item', array(
             'id' => 
             array(
              'type' => 'integer',
              'autoincrement' => '1',
              'primary' => '1',
              'unsigned' => '1',
              'length' => '11',
             ),
             'category_id' => 
             array(
              'type' => 'integer',
              'notnull' => '1',
              'unsigned' => '1',
              'length' => '11',
             ),
             'name' => 
             array(
              'type' => 'string',
              'length' => '255',
             ),
             ), array(
             'primary' => 
             array(
              0 => 'id',
             ),
             ));
    }

    public function down()
    {
        $this->dropTable('item');
    }
}

// lib/migration/doctrine/1283537549_version2.php

class Version2 extends Doctrine_Migration_Base
{
    public function up()
    {
        $this->createForeignKey('item', 'item_category_id_category_id', array(
             'name' => 'item_category_id_category_id',
             'local' => 'category_id',
             'foreign' => 'id',
             'foreignTable' => 'category',
             ));
        $this->addIndex('item', 'item_category_id', array(
             'fields' => 
             array(
              0 => 'category_id',
             ),
             ));
    }

    public function down()
    {
        $this->dropForeignKey('item', 'item_category_id_category_id');
        $this->removeIndex('item', 'item_category_id', array(
             'fields' => 
             array(
              0 => 'category_id',
             ),
             ));
    }
}

3. Lanzar el task $ php symfony doctrine:migrate. Aplica en la BBDD los cambios que se crearon en el paso anterior. Se le pueden pasar parámetros (entorno, up / down, etc.)

4. Por último se reconstruyen las clases del modelo: $ php symfony doctrine:build --all-classes

5. No nos olvidemos de borrar la cache..

Con esto, ya tenemos los cambios que requerimos, aplicados tanto en nuestro proyecto Symfony como en nuestra BBDD. Fácil y rápido.

Enlaces:

Proyecto de prueba creado para el post

Documentación doctrine migrations

Transparencia presentada en Symfony Live 2010 por Dennis

Para ello normalmente existen dos vías diferentes: desde el generator.yml o sobreescribiendo el partial correspondiente a las acciones del form o list.

Este sería un ejemplo para una acción que pondrá un artículo en la portada de la web:

Desde el generator.yml: 

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Articulos
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          articulos
    with_doctrine_route:   true
    actions_base_class:    sfActions

    config:
      actions: ~
      list:    ~
      filter:  ~
      form:
          actions:
              portada:
                  action:  'inHome' 
                  label:   'En portada'
                  confirm: 'Este artículo pasará a la portada de la web. Continuar?'
              _delete: ~
              _list:   ~
              _save_:  ~
      edit:  ~
      new:  ~

Sobreescribiendo _form_actions.php

<ul class="sf_admin_actions">
<?php if ($form->isNew()): ?>
  <?php // Si es un objeto nuevo no se muestra el botón ?>
  <?php // Aquí irían las acciones propias del Form: edit, save... ?>
<?php else: ?>
  <?php if (!$articulos->getInHome()): ?>
  <li class="sf_admin_action_portada">
  <?php echo link_to(__('En portada', array(), 'messages'), 'articulos/inHome?id='.$articulos->getId(), array(  'conditional' => 'portada',  'conditional_value' => false,)) ?>
  </li>
  <?php endif; ?>
  <?php // Aquí irían las acciones propias del Form: edit, save... ?>
<?php endif; ?>
</ul>

Esta última opción da más control al programador y se pueden tener en cuenta condicionales como por ejemplo que el artículo tenga el campo home=true, en cuyo caso ya no se necesita que aparezca el botón.

Pero las opciones no se acaban aquí, existe otro método de crear nuevas acciones un poco más complejas sin necesidad de sobreescribir el elemento Partial. Cómo? Haciendo uso del Helper propio del módulo creado por el Admin Generator (Articulos en este ejemplo). Este archivo se sitúa en el directorio lib del módulo: apps/backend/modules/##moduleName/lib/##moduleNameGeneratorHelper.class.php y extiende de Base##moduleNameGeneratorHelper que ha su vez extiende de la clase sfModelGeneratorHelper. Si miramos esta clase vemos que contiene los helpers linkToNew, linkToEdit, linkToList, linkToSave y linkToSaveAndAdd que se corresponden con las acciones base y que devuelven el tag li con una llamada al helper link_to configurado con los parámetros de la acción.

Si se mira el Partial de las acciones, primero se comprueba que exista el método ##actionName dentro del helper, si existe se muestra su valor, si no existe se crea la acción parametrizada según el fichero generator.yml

cache/backend/#env/modules/autoArticulos/templates/_form_actions.php

<?php 
 // ... 
 if (method_exists($helper, 'linkToPortada')): ?>
  <?php echo $helper->linkToPortada($form->getObject(), array(  'action' => 'inHome',  'label' => 'En portada',  'confirm' => 'Este artículo pasará a la portada de la web. Continuar?',  'params' =>   array(    'conditional' => 'portada',    'conditional_value' => false,  ),  'class_suffix' => 'portada',)) ?>
<?php else: ?>
  <?php echo link_to(__('En portada', array(), 'messages'), 'articulos/inHome?id='.$articulos->getId(), array(  'conditional' => 'portada',  'conditional_value' => false,)) ?>
<?php endif; 
  // ...
?>

Entonces, una forma de personalizar acciones es usando el generator.yml y el helper del módulo para pasárle parámetros, condicionales, etc. Siguiendo con el ejemplo:

generator.yml

generator:
  class: sfDoctrineGenerator
  param:
    config:
      form:
        actions:
          novedad: 
            action:  'inNew' 
              label:   'Novedad' 
              confirm: 'Este artículo será marcado como novedad. Continuar?'
              params:
                conditional: 'novedad'
                conditional_value: false

El parámetro 'novedad' se usará para saber qué propiedad del objeto hay que chequear y el parámetro conditional_value para saber qué valor ha de tomar el objeto para que se muestre esta acción.

articulosGeneratorHelper.class.php

<?php 

class articulosGeneratorHelper extends BaseArticulosGeneratorHelper
{
  public function linkToPortada($object, $params)
  {
    $conditional = (isset($params['params']['conditional'])) ? 'get'.ucfirst($params['params']['conditional']) : null;
    $conditional_value = (isset($params['params']['conditional_value'])) ? $params['params']['conditional_value'] : true;
    if ( ($conditional == null) || ($conditional != null && $object->$conditional() == $conditional_value) ) {
      return link_to(__($params['label'], array(), 'sf_admin'), 'articulos/' . $params['action'] . '?id=' . $object, array('confirm' => !empty($params['confirm']) ? __($params['confirm'], array(), 'sf_admin') : $params['confirm']));
    } else {
      return '';
    }
  }
}

Tengo que decir que no he visto nada en la documentación oficial de Symfony al respecto, por lo que no se hasta qué punto es una forma correcta de hacer uso de ésto, sobre todo con el paso de parámetros no estándares (conditional y conditional_value) desde el generator.yml al helper del módulo.

Tras echarle un ojo, vi que implementa basicamente lo que necesito para mi carro de la compra y que solo requería de algunas modificaciones para hacerlo compatible con Doctrine, por lo que decidí hacer uso de él.

El plugin en si consta solamente con dos clases:

• sfShoppingCart: que se encarga de modelar la cesta como tal y sus operaciones básicas (añadido, borrado, etc.)
• sfShoppingCartItem: que modela un item que se añadirá a sfShoppingCart.

Básicamente, el uso es el siguiente:

<?php

// Se crea el objeto de la cesta
$carrito = new sfShoppingCart(sfConfig::get('app_tax'));
// Se añade un nuevo Articulo al carrito
$article = ArticlesTable::getInstance()->find($request->getParameter('id'));
$articleItem = new sfShoppingCartItem(get_class($article), $article->getId());
$articleItem->setPrice($article->getPrice());
$articleItem->setQuantity($request->getParameter('quantity'));
$carrito->addItem($articleItem);
// Recorrer el carrito y ver el precio total
foreach ($carrito->getItems() as $item) {
    echo sprintf(
        '%d: %f x %d = %f', 
        $item->getId(), 
        $item->getPrice(), 
        $item->getQuantity(), 
        ($item->getPrice() * $item->getQuantity())
    );
}
echo 'Total: ' . $carrito->getTotal();

Además de estas operaciones la clase sfShoppingCart incluye dos operaciones que devuelven el objeto Item del modelo:

sfShoppingCart::getObjects()
sfShoppingCart::getObject($class, $id)

Estos métodos hacen uso de Propel para obtener el objeto de la clase $class y con id $id.

Como lo que necesito es hacer uso de Doctrine, nada mejor que extender sfShoppingCart a sfDoctrineShoppingCart y sobreescribir ambos métodos:

  public function getObject($class, $id)
   {
     // We must first make sure that the requested object does exist in the shopping cart
     $ind = $this->getItemIndice($class, $id);
     
     return (($ind !== null) ? call_user_func(array($class.'Table', 'find'), $id) : null);
   }
 
   public function getObjects()
   {
     $object_ids = array();
     foreach ($this->getItems() as $item)
     {
       if (!array_key_exists($item->getClass(), $object_ids))
       {
         $object_ids[$item->getClass()] = array();
       }
 
       $object_ids[$item->getClass()][] = $item->getId();
     }
 
     $objects = array();
     foreach ($object_ids as $class => $ids)
     {
       $objects = array_merge(
         $objects, 
         Doctrine::getTable($class)->createQuery('c')->whereIn('c.id', $ids)->execute()->getData()
       );
     }
 
     return $objects;
   }

Con ésto ya se puede hacer uso de la clase sfDoctrineShoppingCart con todas las funcionalidades que ofrece sfShoppingCart pero adaptado a Doctrine.

Además he implementado algunos métodos extra para hacerlo más cómodo al uso. Por ejemplo sfDoctrineShoppingCart::getInstance() o sfDoctrineShoppingCart::save() para obtener y almacenar el carrito

Plugin sfShoppingCart de Fabien Potencier.

Ejemplo de uso para 1.0

Clase sfDoctrineShoppingCart

Voy a experimentar durante un tiempo a ver qué ocurre...

Pueden seguirme en Alberto Ramirez on Twitter

El cambio a la hora de codificar es significativo, no puedo comentar nada nuevo que no se haya comentado ya al respecto de las novedades de estas versiones sobre la 1.0.

En mi caso, la integración con el subframework de formularios aun continua su proceso, me manejo mucho mejor que al principio, pero aun hay muchos aspectos que desconozco.

El sistema de enrutamiento lo veo muy cómodo, ya que permite establecer en el routing.yml los parámetros del objeto que vas a pasar por URL de modo que a la hora de llamar al helper link_to, solo con pasarle el objeto completo, éste ya se encarga de formatear la URL. Además con los comportamientos (behaviors) de Doctrine, también se pueden definir Slug de forma muy sencilla.

Ejemplo:

routing.yml

watch_show:
  url:   /catalogo/:brand_url/:slug
  class: sfDoctrineRoute
  options: { model: Watch, type: object }
  param: { module: watch, action: show }
  requirements:
    id: \d+
    sf_method: [get]

showSuccess.php

url_for('watch_show', $principalWatch)

lib/model/doctrine/Watch.class.php

public function getBrandUrl()
{
    return $this->getBrand()->getSlug();
}

schema.yml

Watch:
  tableName: watch
  actAs:
    Timestampable: ~
    Sluggable:
      unique: true
      fields:  [model_name]
      canUpdate: true

apps/frontend/modules/watch/actions/actions.class.php

public function executeShow(sfWebRequest $request)
{
    // 'watch_show' 
    $this->watch = $this->getRoute()->getObject();
}

Otro de los cambios importantes es el paso a Doctrine como ORM en defecto de Propel. Lo noto muy flexible, fácil de aprender pero por completo diferente a Propel. Los retrieves se hacen en base a la clase Doctrine_Query y vas formando query de una forma mucho más gráfica y no tan complejas como con Criteria de Propel.

Ejemplo de Query:

$q = Doctrine::getTable('Articulos')->createQuery('a')
        ->leftJoin('a.Familias f')
        ->leftJoin('a.Subfamilias sf')
        ->innerJoin('a.fotos ft')
        ->where('a.pagarias = ?',false)
        ->andWhere('a.agotado = ?', false)
        ->andWhere('a.familia = f.id')
        ->orderBy('a.portada DESC')
        ->limit(23)
;

Doctrine cuenta con una tabla que modela el objeto en si "Articulos" (en este ejemplo) y con una clase destinada a las operaciones de consulta a la tabla "ArticulosTable" (siguiendo con el ejemplo).

Existen muchas más cosas a tener en cuenta. Por lo que es recomendable leer las novedades de cada versión con el fin de tener en mente las nuevas funcionalidades que aporta cada versión de Symfony.

Yo acabo de pedir el libro Más con Symfony que está destinado a los programadores que conocen bien el entorno y quieren ser aun más productivos con Symfony.

¿Cómo usarlo?

Hay que usar Firefox y tener instalado el complemento Firebug (que seguro que lo tienes ya), luego hay que instalar FirePHP y descargar e instalar la librería PHP.

Una vez obtenido el complemento e instalada la librería se puede usar de esta forma:

require_once('FirePHPCore/FirePHP.class.php');
$firephp = FirePHP::getInstance(true);
$firephp->log('Hello World');

Se pueden loguear variables, costantes, arrays, objetos, etc.

Para Symfony

Si se está usando Symfony como framework para el desarrollo se puede instalar el plugin sfFirePHP e integrarlo en su funcionamiento (sistema de log, barra de depuración web, etc).

Enlaces:

Instalación.

Ejemplos de uso.

sfFirePHP.

Este sería un pequeño script PHP de ejemplo.

ob_start();
for($x=0; $x<10; $x++){
  echo printf('- Línea %d.'."\n", $x);
  ob_flush();
  flush();
  sleep(1);
}
ob_end_flush();

Aunque es muy sencillo, lo que realiza es lo siguiente:

1. Inicia el Buffer de PHP.
2. Comienza un bucle que imprime una línea de código cualquiera.
3. Limpia el contenido del buffer y lo saca por la salida estándar.
4. Duerme el script PHP durante 1 segundo (para simular la escritura mediante una carga asíncrona).
5. Termina el buffer.

• Aun no se conoce (o no de forma correcta) el dominio sobre el cual va a actuar el software.
• Tampoco se tiene de forma detallada y formal la problemática que ha de resolverse.
• No se conocen las necesidades de los usuarios finales del SW de una forma completa.
• Estos puntos llevan a crear métodos y funciones con funcionalidades repetitivas o inversas, por lo que no se hace uso de reutilización de software de manera eficiente.
• Tampoco se tiene en cuenta la refactorización.
• El software será menos escalable y tendrá problemas de mantenimiento posterior.

Se podrían seguir enumerando desventajas, pero no voy a seguir aquí eternamente. ¿Qué se debe hacer pues, antes de ponerse a programar una nueva aplicación?

Para solucionar estos problemas y crear una aplicación sólida, escalable y de fácil mantenimiento hay que empezar por unos cimientos sólidos, y para este propósito nada mejor que guiarnos por algún ciclo de vida del software conocido.

Las etapas varían dentro de cada ciclo de vida, pero yo me centraré en comentar las siguientes:

1. Documentación y recogida de requisitos.
2. Análisis.
3. Diseño.
4. Implementación.

Documentación y recogida de requisitos.

Esta etapa comprende las sucesivas entrevistas con el cliente y con los usuarios que usarán la aplicación. Ellos han de transmitir qué necesitan y qué problemática debe de solucionar el nuevo software.

En esta etapa podemos empezar a hacer uso de ciertos diagramas que permitan ponernos de acuerdo con el cliente, pero por ello mismo la notación no puede ser completamente formal ya que, de tal modo, no sería legible para el cliente.

Los diagramas que se pueden usar en esta etapa son:

• Casos de uso: este diagrama ayudará a conocer los actores que intervendrán en la aplicación. Los actores pueden ser personas (o mejor dicho, papeles que tomarán éstos) u otros sistemas de software externo que hagan uso directo de la aplicación. Cada actor tendrá asociación directa con uno o más casos de uso. Un caso de uso es una funcionalidad comprendida en el dominio del SW (crear factura, buscar factura, etc.).
• Diagrama estático de clases: se notarán las clases más importantes dentro del dominio, los atributos de cada una y las relaciones entre estas clases. Por ejemplo clase Factura, Cliente, Compra, etc.

Análisis.

Una vez redactado el informe de especificación de requisitos, documentado en el punto anterior, se pasa a la etapa de análisis, esta etapa hace de puente entre la documentación y el diseño y su cometido es el de revisar, formalizar y ver funcionalidades que no se tuvieran en cuenta en la etapa anterior. En la etapa del análisis se puede usar UML estándar ya que la documentación creada en esta etapa será visible para analistas y programadores.

Los pasos de esta etapa:

• Revisión de los casos de uso. Este es el momento de ampliar el diagrama de los casos de uso con la finalidad de documentar todos y cada uno de los casos de uso y actores del nuevo sistema.
• Revisión del diagrama de clases: para tener en cuenta casos especiales de atributos, herencias, interfaces, agregaciones, etc.

Diseño.

Es el paso previo a la escritura de código (implementación), aquí es donde se tienen en cuenta la reutilización de código (uso de librerías, frameworks, clases, patrones de diseño, componentes, etc.), la persistencia de los datos (sistema de BBDD y diseño de ésta), normalización del diagrama de clases según el lenguaje de programación elegido.

Implementación.

Una vez documentados todos los puntos anteriores y con los diagramas de casos de uso, de clases, entidad-relación de BBDD y alguno opcional como: secuencias, estados, colaboración, etc. Es la hora de empezar a escribir código. ¿Contento por ésto? bien, pues puedes estar contento por dos veces ya que además de empezar la codificación del proyecto a tu lenguaje de programación favorito (o en su defecto, el elegido), también ahorrarás una gran cantidad de tiempo gracias a que todas (o la gran mayoría) de funcionalidades están documentadas de una manera formal, se tienen en cuenta grandes masas de reutilización de código, refactorización, etc. Que te ahorrarán grandes dolores de cabeza, errores, multitud de pruebas, etc.

Para ampliar conocimientos acerca de este tema, hay multitud de libros de Ingeniería del Software, UML, patrones de diseño (design pattern) y ciclo de vida del software.

- Ejemplo 1:

    $connection = new DbConnection($host, $user, $pass);
    // Esta forma no sería la adecuada
    
    // Conexion creada mediante un método estático regido por el patron "Factory",
    // que aisla el código de la conexion a la base de datos
    $connection = DbConnection::createConnection(); 
    // Esta forma seria la correcta.
?>

- Ejemplo 2:

    // La clase Application configura la aplicacion, en este caso se instancia
    // mediante su constructor y el paso de ciertos parametros.
    $application = new Application(array(
        'app_name' => 'appTest',
        'version'  => '1.0',
        'path'       => '/'
    ));
    
    // De esta forma la configuracion se hace a traves del metodo
    // configure de una forma sencilla. configure() se rige por el patron
    // Factory
    $application = Application::configure();
?>

¿ Qué pasaría en caso de no utilizar el patrón Factory si es necesario cambiar la estructura de los objetos ? habría que ir objeto por objeto de la clase reformada cambiando su estructura y adaptándolo a su nueva forma, la pérdida de tiempo que esto ocasionaría se incrementa por el número de objetos que se crean en la aplicación y la complejidad de estos.

Sin embargo, si se utiliza un método regido por "Factory" para crear los objetos, la adaptación de estos a la nueva estructura vendría por la modificación única en el método que crea la instancia, con lo cual la pérdida de tiempo es mínima, sin hablar de la posibilidad de errores que se pueden cometer si el número de objetos a modificar es elevado.

El patrón "Factory" no es solo aplicable a la clase, es decir, se puede crear un método interno de una clase para que el resto de métodos de la clase puedan llamar a un código necesario en cada uno de ellos sin necesidad de repetir éste:

<?php
    class DbActions{
        public function list(){
            $connection = $this->_getConnection();
            // código a ejecutar para sacar el listado
        }
        
        public function getById($id){
            $connection = $this->_getConnection();
            // código a ejecutar para obtener el registro
            // mediante la id pasada
        }
        
        // _getConnection aisla y devuelve la conexion
        private function _getConnection(){
            return new DbConnection(
                DB_HOST,
                DB_USER,
                DB_PASS
            );
        }
    }
?>

Una vez explicada la funcionalidad del patrón "Factory" se puede aplicar a un ejemplo más complejo:

Archivo index.php

<?php    
    // Comienza la ejecucion del programa: 
    
    // se instancia Application, con los datos 
    // necesarios para la ejecucion.
    // Se hace uso de Singleton para la instancia.
    require_once ('application.php');
    $application = Application::getInstance();
    
    // Ejecucion de un query.
    $results = $application->db->executeQuery("SELECT * FROM `porfolio`");
    
?>

Archivo application.php

<?php
    
    class Application{
        
        /**
        * $instance = Object
        */
        private static $instance = null;
        
        /**
        * Contiene un objeto de la clase que conecta a la BBDD.
        * $db = DbConex Class
        */
        public $db = null;
        
        /**
        * private __construct
        */
        private function __construct(){
            // Conexion a la BBDD
            require_once ('dbconex.php');
            // create_connection es un metodo regido por "Factory"
            // que abstrae la logica de configuracion, conexion
            // y acceso a la BBDD.
            // Solo requiere el motor de BBDD como parámetro
            $this->db = DbConex::create_connection('MySQL');
        }
        
        /**
        * Metodo que devuelve la instancia (si no existe la crea) de
        * la clase Application. Se rige por "Singlenton".
        *
        * @return Application
        */
        public function getInstance(){
            if (is_null(Application::$instance)) {
                Application::$instance = new Application();
            }
            return Application::$instance;
        }
    }
?>

Archivo dbconex.php

<?php
    /**
    *    Clase padre regida por "Factory" que inicializa
    *    la conexion a la base de datos
    *    
    *    @return DbConex
    */
    abstract class DbConex
    {
        /**
        * datos de conexion
        */
        protected $data = array(
            'db_host'    =>     'localhost',
            'db_user'    =>     'user_test',
            'db_pass'    =>     'user_test'
        );
        
        /**
        * Identificador de la conexion
        */
        public $resource = null;
        
        /**
        * Es el metodo que instancia la subclase que va
        * a conectar a la base de datos.
        * @param: $type
        *
        * @return Object
        */
        public static function create_connection($type){
            switch ($type) {
                case 'MySQL':
                    $db = new MySQLDbConex();
                    break;
                case 'Oracle':
                    $db = new OracleDbConex();
                case 'PostgreSQL':
                    $db = new PostgreSQLDbConex();
            }
            return $db;
        }
        
        /**
        * metodo que ha de ser sobreescrito por las clases
        * hijas que se va a encargar de realizar la consulta
        * SQL.
        * @param $sql = String
        *
        * @return mixed
        */
        abstract public function executeQuery($sql);
    }
    
    class MySQLDbConex extends DbConex{
        
        public function __construct(){
            $this->resource = mysql_connect(
                $this->data['db_host'],
                $this->data['db_user'],
                $this->data['db_pass']
            );
            mysql_select_db('aramirez', $this->resource);
        }
        
        public function executeQuery($sql){
            // Codigo de ejecucion del Query SQL
        }
    }
    
    class OracleDbConex extends DbConex{
        public function __construct(){
            // Codigo de conexxion a Oracle
        }

        public function executeQuery($sql){
            // Codigo de ejecucion del Query SQL
        }
    }

    class PostgreSQLDbConex extends DbConex{
        public function __construct(){
            // Codigo de conexxion a PostgreSQL
        }

        public function executeQuery($sql){
            // Codigo de ejecucion del Query SQL
        }
    }
?>

En ciertas ocasiones se necesita que una clase en concreto mantenga la misma y única instancia a lo largo de toda la ejecución del programa, sin permitir que se cree un objeto diferente de esa clase.

Podemos pensar en una cesta de la compra como ejemplo, cuando un cliente entra en la tienda se instancia un objeto de la clase que gestiona la cesta, si en otro punto del programa se necesita recurrir a la cesta, el objeto devuelto ha de ser el mismo que el anterior y no uno nuevo. Otro ejemplo puede ser el de la conexión a una base de datos: cuando el programa comienza se crea la conexión, y lo óptimo es que todas las operaciones SQL se hagan a través de la misma conexión abierta, así se ahorra en tiempo de ejecución ya que no hay que abrir, ejecutar y cerrar cada vez que se requiera de una operación SQL, además en el caso de una aplicación de comercio electrónico se puede requerir que el identificador de conexión sea siempre el mismo para ejecutar transacciones.

De este razonamiento sacamos un problema en común:

¿Cómo se puede restringir que una clase solo devuelva una única instancia de ella lo largo de toda la ejecución del programa?

Para resolver este problema se usa el patrón de diseño Singleton: una clase basada en este patrón instancia e inicializa un objeto y provee de acceso para extraer el mismo objeto cada vez. Todo ello a través de un método comúnmente llamado getInstance().

¿Cómo se implementa?

• Se declara una propiedad de la clase con visibilidad privada que va a contener en todo momento la instancia de la clase.
• Se establece como privado el constructor de la clase.
• Se crea un método de acceso público getInstance que se encargará de devolver la instancia de la clase si existe, y si no existe la crea previamente.

Ejemplo: Para el ejemplo vamos a usar una clase que contiene toda la lógica de base de datos (conexión, ejecución de SQL, etc.) y que se rige por el patron Singleon.

Clase dbConex:

<?php
    /**
    *    Clase que devuelve la instancia de la conexion
    *    a la base de datos, si no existe la abre.
    *    Sigue el patron de diseño Singleton
    */
    class DbConex
    {
        /**
        * Propiedad privada que almacena la instancia
        */
        private static $instance = null;
        /**
        * Propiedad publica que almacena el ultimo query ejecutado con exito
        */
        public $lastQuery = "";
        
        /**
        * Constructor de la clase, con acceso privado
        */
        private function __construct(){
            
        }
        
        /**
        * Metodo que devuelve la instancia de la clase si existe,
        * si no la crea previamente
        *
        * @return Object
        */
        public static function getInstance(){
            if (is_null(DbConex::$instance)) {
                DbConex::$instance = new DbConex();
            }
            return DbConex::$instance;
        }
        
        /**
        * Metodo que ejecuta un query SQL
        * y lo almacena en una variable como ultimo query ejecutado
        *
        * @param $query = String
        */
        public function executeQuery($query){
            // .. Codigo que ejecuta el Query ..
            $this->lastQuery = $query;
        }
    }

Como se ve en este código el método getInstance comprueba si existe la instancia de DbConex accediendo a la propiedad estática $instance, si no existe la crea y la almacena en dicha propiedad, por último devuelve $instance.

Adicionalmente he creado una propiedad $lastQuery que almacena el último query ejecutado con éxito. La finalidad de esto es poder comprobar la ejecución del Singleton.

El método executeQuery se encarga de ejecutar el SQL pasado como parámetro y almacenar el query en la propiedad $lastQuery. Este método va a ayudar a comprobar la funcionalidad del singleton.

Ahora se muestra el script PHP que llama y ejecuta la clase DbConex para realizar la prueba del Singleton:

<?php
    // Se insertan todos los archivos necesarios
    require_once ('dbconex.php');
    
    // Comienza la aplicacion
    
    // Se instancia la clase DbConex, se ejecuta un Query y se elimina la variable de memoria
    $dbConex = DbConex::getInstance();
    $dbConex->executeQuery("SELECT table1.id, table1.name FROM table1;");
    unset($dbConex);
    // Hemos terminado con la conexion en este punto
    
    // Simulamos otro punto de la aplicacion:
    // Volvemos a crear una instancia de dbConex
    $dbConex2 = DbConex::getInstance();
    // Para comprobar que el objeto devuelto es el mismo 
    // mostramos el ultimo query ejecutado
    echo sprintf("Last SQL: %s \r\n", $dbConex2->lastQuery);

Como se puede ver primero se crea una instancia de DbConex y se ejecuta un SELECT cualquiera, luego se elimina la variable que contiene la instancia de DbConex.
Más adelante se simula otro punto de la aplicación instanciando de nuevo la clase DbConex, si esta clase no siguiese el patrón Singleton el objeto devuelto sería otro creado desde cero, pero como no es así, el objeto es el mismo que se creo en el punto anterior de la aplicación. Para demostrarlo se imprime en la salida la propiedad $lastQuery, que contiene el SQL ejecutado con éxito anteriormente.

Como podéis ver este patrón es muy útil en ciertas ocasiones y puede ser la solución a un problema que se nos presenta a menudo.

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

En realidad los patrones de diseño nacen de la solución a problemas comunes, tienen ventajas y desventajas, pero normalmente sus ventajas hacen que usarlos sea la solución óptima a un problema concreto. Por ejemplo, si necesitamos asegurarnos de que una clase cualquiera solo sea instanciada una vez a lo largo de la ejecución de la aplicación (como la conexión a la base de datos) podremos recurrir al patrón de diseño Singleton. O para separar en capas la lógica de negocio, el controlador de la aplicación y la vista, se puede usar el patrón MVC.

Para formarme en este campo, he mirado diferentes libros que tratan esta temática y al final he optado por "phparchitect's. Guide PHP Design Patterns" en magnífico inglés :D.

A lo largo de una serie de post iré describiendo los patrones que creo, pueden se los más interesantes para los programadores PHP en el mundo web.

Capítulos:

1. Patrón Singleton.
2. Patrón Factory.

Enlaces:

wikipedia :: patrón de diseño

 <?php
     // Se abre el canal RSS
     $feed = sfFeedPeer::newInstance('rss201');
     $feed->setTitle("Canal Podcast de prueba");
     $feed->setLink('http://www.dominio.com/');
     $feed->setAuthorName('Alberto Ramírez');
     $feedImage = new sfFeedImage();
     $feedImage->setFavicon('http://www.dominio.com/favicon.ico');
     $feed->setImage($feedImage);
 
     // Ahora se crean las entradas del canal
     $articulos = ArticulosPeer::getFeeds(); // metodo del modelo que devuelve los ultimos articulos
     foreach ($articulos as $entrada){
         // Se declara el item
         $item = new sfFeedItem();
         $item->setTitle($entrada->getTitulo());
         $item->setLink('http://www.dominio.com/'.$entrada->getId());
         $item->setPubdate($entrada->getFechaPublicacion('U'));
         $item->setUniqueId($entrada->getId());
         
         // Se declara el objeto enclosure con los datos
         // url, tamaño y mime del archivo
         $enclosure = new sfFeedEnclosure();
         $enclosure->initialize(array(
             'url'        => 'http://www.dominio.com/podcast/file.mp3',
             'length'   => 3072,
             'mimeType' => 'audio/mpeg'
         ));
         // Se asigna al item del feed
         $item->setEnclosure($enclosure);
         
         // Se añade el item al canal
         $feed->addItem($item);
     }
     // Paso de variables al template
     $this->feed = $feed;
 ?>
 

Luego en el template convertimos el objeto Feed en XML:

 <?php decorate_with(false) ?>
 <?php echo $feed->asXml() ?>
 

Con esto ya tenemos creado un canal podcast básico creado.