Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas

Patrones de diseño - Factory

0 comentarios


Patrones de Diseño.

El patrón Factory, nos permitirá centralizar en una clase la creación de objetos de un mismo tipo. Definiremos una interfaz o una clase abstracta para crear un objeto, pero serán las subclases quienes decidan qué clase se va a instanciar, permitiendo que una clase delegue a sus subclases la creación de objetos. A continuación vamos a explicarlo más a fondo:

Clasificación

Creacional

Intención

Centraliza en una clase constructora la creación de objetos de un mismo subtipo de un tipo determinado.

Motivación

El patrónFactory es bastante útil cuando no se sabe de antemano que tipo de objeto de una familia se va a instanciar, sino que durante el proceso se decidirá que tipo hacerlo. Por ejemplo, procesar un fichero de configuración json, xml, yui, txt y es una variable la que nos indica que fichero se parseará.

Aplicabilidad

  • Una clase no puede prever la clase de objetos que debe crear
  • Centralizar la creación de objetos. Una clase quiere que sean sus subclases quienes especifiquen los objetos que ésta crea.
  • Delegar la responsabilidad en una de entre varias clases auxiliares, permitiendo crear una familia de objetos.

Estructura

Consecuencias

Proporciona más flexibilidad a la hora de crear objetos de una misma familia de objetos dentro de una clase.

Participantes

· Producto Define la interfaz de los objetos que crea el método de fabricación.
· Producto Concreto Implementa la interfaz del Producto.
· Creador Declara el método de fabricación que devolverá un objeto del tipo Producto. Puede definir una implementación predeterminada del método de fabricación.
· Creador Concreto Redefine el método de fabricación para devolver una instancia del Producto Concreto.

Implementación

La clase UserFactory tiene un método estático Create() que recibe como parámetro 2 argumentos. Según el valor de estos se decide que subclase se va a instanciar.

Código de ejemplo

Aunque existen bastantes variaciones del patrón Factory, las dos más utilizadas són:
- El creador es clase concreta que implementa una interfaz predeterminada para el método de creación.
- El creador es abstracto y no provee implementación par el método de creación.

Creador: es una Clase abstracta o Interfaz

Ahora vamos a mostrar varios ejemplos. En el primero, la Factory es una interfaz que crea las instancias GuestUser, ActiveUser y AdminUser, las cuales son denominadas productos en este tipo de patrón.
Clases User y subtipos: user.php
    /**
     * Clase abstracta User. De esta clase extenderá la familia 
     * de objetos de tipos de usuarios
     */
    abstract class User {
        protected $username = null;

        public function __construct($username) {
            $this->username = $username;
        }

        public function getPermissions() {
             return false;
        }

        public function getSuperPrivileges() {
             return false;
        }
    }

    // Clase GuestUser: User
    class GuestUser extends User {}

    // Clase ActiveUser: User
    class ActiveUser extends User {
        public getPermissions() {
            return true;
        }
    }

    // Clase AdminUser: User
    class AdminUser extends User {
        public getPermissions() {
            return true;
        }

       public function getSuperPrivileges() {
             return true;
        }
    }
    
Patrón Factory: user_factory.php
    
    /**
     * Creador sin implementación. Puede ser una inferface o 
     * una clase abstracta donde no se definan la implementación 
     * de los métodos de creación.
     */
    interface FactoryInterface {

         /** 
          * Método de creación.
          * 
          * @static
          * @param String $username Nombre de usuario
          * @param String $privilege Tipo de usuario. 
          * @access public
          */
        static public function Create($username, $privilege);
    }

    // UserFactory: FactoryInterface
    /**
     * Creador concreto que implementa la interfaz de creación.
     */
    class UserFactory implements FactoryInterface {

         // Datos "hardcoded" para realizar demostración
         private static $users = array(
             'jose'    => 'Guest',
             'jesus'   => 'Active',
             'zonadev' => 'Admin'
         );

         /** 
          * Método de creación. Retorna una instancia del objeto. Se obtiene que objeto
          * instanciar según el valor de $privilege.
          * 
          * @static
          * @param String $username Nombre de usuario
          * @access public
          */
        static public function Create($username) {
            if(isset(self::$users[$username])) {
                $privilege = self::$users[$username];

                $fry = ucfirst($privilege) . 'User';
                if(class_exists($fry)) {
                    return new {$fry}($username);
                } else {
                    throw new Exception('El tipo de usuario indicado no es correcto.');
                }
            } else {
                return new GuestUser($username);
            }
        }
    }
    
Ejemplo de implementación: privileges.php
    include_once 'user.php';
    include_once 'user_factory.php';

    function checkPermissions(User $o) {
        return $o->getPermissions();
    }
    
    function checkSuperPriivleges(User $o) {
        return $o->getSuperPrivileges();
    }

    echo checkPermissions(UserFactory::Create('zonadev'));
    echo checkSuperPrivileges(UserFactory::Create('zonadev'));
    
Próximamente añadiré más ejemplos con las diferentes formas de implementar la creación de objetos

Patrones relacionados

  • Patrón Abstract Factory

Referencias


Patrones de diseño

2 comentarios

Que són los Patrones de diseño del Software

En el mundo de la programación escuchamos bastante a menudo hablar sobre "Patrones de diseño" y la primera vez, las preguntas que nos hemos hecho todos son las mismas. ¿Qué son y para qué sirven?
Podemos definir un patrón de diseño, como una base para la búsqueda de soluciones a problemas que encontramos comúnmente durante el desarrollo de software. Para que una solución sea considerada un patrón, debe haberse demostrado en otras ocasiones su efectividad y que esa misma solución es reutilizable para cualquier situación similar.
Podemos encontrar 3 tipos fundamentales de patrones: de creación, estructurales y de comportamiento, además de un cuarto tipo que utilizaremos para aplicaciones concurrentes. Paso a listar los patrones más conocidos.
En futuros posts, iré explicando los patrones uno por uno, con ejemplos de implementación y explicando cuando y porqué los utilizaremos. No lo hago en este post directamente porque se haría demasiado largo y pesado de leer, así que he preferido ir paso a paso y hacer primero una primera introducción.

Relación de Patrones:

  • 1 Patrones de creación
    • 1.1 Patrón Factory (Factoría)
    • 1.2 Patrón Abstract Factory (Factoría Abstracta)
    • 1.3 Patrón Builder (Constructor)
    • 1.4 Patrón Singleton (Instancia 
      • Shallow copy
      • Deep Copy
    • 1.5 Patrón Prototype (Prototipo)
    • 1.6 Patrón Lazy initialization
    • 1.7 Patrón Multiton
    • 1.8 Patrón Object Pool
  • 2 Patrones estructurales
    • 2.1 Patrón Adapter (Adaptador)
    • 2.2 Patrón Bridge (Puente)
    • 2.3 Patrón Composite (Composición)
    • 2.4 Patrón Decorator (Decorador)
    • 2.5 Patrón Facade (Fachada)
    • 2.6 Patrón Front Controller
    • 2.7 Patrón FlyWeight
    • 2.8 Patrón Proxy
    • 2.9 Patrón Module
  • 3 Patrones de comportamiento
    • 3.1 Patrón Blackboard
    • 3.2 Patrón Chain of responsibility (Cadena de Responsabilidad)
    • 3.3 Patrón Command (Comando)
    • 3.4 Patrón Interpreter (Intérprete)
    • 3.5 Patrón Iterator (Iterador)
    • 3.6 Patrón Mediator (Mediador)
    • 3.7 Patrón Memento (Recuerdo)
    • 3.8 Patrón Null Object
    • 3.9 Patrón Observer (Observador)
    • 3.10 Patrón Servant
    • 3.11 Patrón Specification
    • 3.12 Patrón State (Estado)
    • 3.13 Patrón Strategy (Estrategia)
    • 3.14 Patrón Template (Plantilla)
    • 3.15 Patrón Visitor (Visitante)
  • 4 Patrones para aplicaciones concurrentes
    • 4.1 Patrón Active Object
    • 4.2 Patrón Balking
    • 4.3 Patrón Binding properties
    • 4.4 Patrón Messaging design pattern (MDP)
    • 4.5 Patrón Double-checked locking
    • 4.6 Patrón Event-based asynchronous
    • 4.7 Patrón Guarded suspension
    • 4.8 Patrón Lock
    • 4.9 Patrón Monitor object
    • 4.10 Patrón Reactor
    • 4.11 Patrón Read-write lock
    • 4.12 Patrón Scheduler
    • 4.13 Patrón Thread pool
    • 4.14 Patrón Thread-specific storage
    • 4.15 Patrón Unit of Work
Referencias:
Para estudiar todo el tema de patrones, estoy utilizando la información disponible en los siguientes enlaces, los cuales os recomiendo si queréis meteros a fondo en el estudio de patrones de diseño:

Interfaces y clases abstractas en PHP

0 comentarios

En este post explicaremos que son las interfaces y las clases abstractas, y para que utilizaremos cada una de ellas.

Interfaces

Las interfaces de objetos permiten crear código con el cual especificamos qué métodos deben ser implementados por una clase, sin tener que definir cómo estos métodos son manipulados. Las interfaces son definidas utilizando la palabra clave interface, de la misma forma que con clases estándar, pero sin métodos que tengan su contenido definido. Todos los métodos declarados en una interfaz deben ser public, ya que ésta es la naturaleza de una interfaz.

Por lo general, utilizaremos las interfaces cuando queramos asegurarnos de que una clase implemente una serie de métodos. Veamos un ejemplo:

// Declarar la interfaz 'iTemplate'
interface iTemplate {
    public function setVariable($name, $var);
    public function getHtml($template);
}

// Implementar la interfaz
// Ésto funcionará 
class Template implements iTemplate {
    private $vars = array();
  
    public function setVariable($name, $var) {
        $this->vars[$name] = $var;
    }
  
    public function getHtml($template) {
        foreach($this->vars as $name => $value) {
            $template = str_replace('{' . $name . '}', $value, $template);
        }
 
        return $template;
    }
}

// Ésto no funcionará
// Error fatal: La Clase BadTemplate contiene un método abstracto
// y por lo tanto debe declararse como abstracta (iTemplate::getHtml)
class BadTemplate implements iTemplate {
    private $vars = array();
  
    public function setVariable($name, $var) {
        $this->vars[$name] = $var;
    }
}

Clases abstractas

Mientra que las interfaces sólo nos permiten compartir comportamientos entre objetos no relacionados, las clases abstractas permiten limitar y/o definir con precisión las capacidades de cada objeto. No se puede instanciar directamente a una clase abstracta, sino que habrá que crear otra clase que herede de esta (usando extends) y desde esta se podrán realizar las operaciones sobre los métodos o parámetros de la clase abstracta. En una clase abstracta se pueden definir métodos públicos, que serán accesibles desde las clases heredadas sin necesidad de sobreescribirlas.

Veamos un ejemplo de abstracción de clases:

abstract class AbstractClass
{
    // Forzando la extensión de clase para definir este método
    abstract protected function getValue();
    abstract protected function prefixValue($prefix);

    // Método común
    public function printOut() {
        print $this->getValue() . "\n";
    }
}

class ConcreteClass1 extends AbstractClass
{
    protected function getValue() {
        return "ConcreteClass1";
    }

    public function prefixValue($prefix) {
        return "{$prefix}ConcreteClass1";
    }
}

class ConcreteClass2 extends AbstractClass
{
    public function getValue() {
        return "ConcreteClass2";
    }

    public function prefixValue($prefix) {
        return "{$prefix}ConcreteClass2";
    }
}

$class1 = new ConcreteClass1;
$class1->printOut();
echo $class1->prefixValue('FOO_') ."\n";

$class2 = new ConcreteClass2;
$class2->printOut();
echo $class2->prefixValue('FOO_') ."\n";

En este ejemplo podemos ver como las clases ConcreteClass1 y ConcreteClass2 extienden de AbstractClass y se llama al método abstracto printOut() para mostrar el resultado.

Referencias

Lambda functions y closures en PHP

0 comentarios

Con la versión de PHP 5.3, aparte de los namespaces, otra de las funcionalidades más importantes que se añadieron fue el soporte a las funciones anónimas y los closures. En este post voy a explicar un poco que es cada cosa y como podemos utilizarlo.

Lambda Functions

Las funciones Lambda, (o funciones anónimas), simplemente son aquellas funciones que no tienen nombre. Son muy utilizadas en lenguajes como Javascript. La forma de declarar una función anónima sería la siguiente:

$c = function($a, $b) {
    return sqrt(pow(a, 2) + pow(b, 2));
}

echo $c;

De esta manera, vemos que estamos guardando en $c una referencia a la función anónima. Ahora la pregunta, ¿para que utilizaremos las funciones lambda?. Este tipo de funciones son sobretodo útiles para utilizar callbacks en nuestros métodos. Podemos crear algo parecido a esto:

function greet($value, $callback) {
    echo $callback($value);
}

greet(’ZonaDev’, function($name) {
    return "Hello, $name";
}); 

En este ejemplo, primero definimos la función greet, con dos parámetros, de los cuales el segundo será un callback (una función anónima). En el momento de llamar a la función greet, vemos como le pasamos el nombre y una función anónima que se ejecutará cuando llamamos a echo $callback($value);

Closures

Vamos a ir ahora con las closures, que no son más que funciones anónimas. La única diferencia, es que estas necesitan conocer el valor de alguna variable que se encuentra fuera de la función anónima para realizar sus procesos. Para poder pasarle a una closure una variable externa que utilizará, vamos a utilizar use, vayamos con un ejemplo:

//Simple math class 
class Math
{
    function  __construct($a) {
        $this->a =$a;
    }
    //Returns a closure
    function mul()
    {
        //We can't directly use $this inside closure
        $self = $this;
        return function($n) use($self) {
            return $n*$self->a;
        };
    }
}
$math = new Math(5);
$mul = $math->mul();
echo $mul(4); //Output : 20

En este caso, vemos como dentro de mul creamos una closure y le pasamos una instancia de $this.

Hasta aquí una explicación breve de lo que son las funciones anónimas y como podemos utilizarlas, pronto empezaremos con los patrones de diseño.

Referencias

Namespaces en PHP

0 comentarios

Para empezar, un poco de teoría sobre que son los namespaces (o nombres de espacio). Con la salida de la versión de PHP 5.3, una de las novedades más importantes que se incorporaron fué la posibilidad de utlizar namespaces, como ya se podían hacer en otros lenguajes de programación como eran C, C++ y Java, por ejemplo.

Para entender que es un namespace, podemos recurrir a la definición que encontramos en la propia Wikipedia: Un namespace es "un contenedor abstracto que agrupa de forma lógica varios símbolos e identificadores" y los utilizaremos básicamente, para estructurar mejor nuestro código fuente.

Antes de que salieran los namespaces, en PHP todas las clases, constantes y funciones cargadas se ubican en un espacio global.

Para explicar el uso de namespace, crearé un supuesto modelo desde el cual accederemos después mediante el controlador:

namespace Users\Model;

class UserModel {

    private String $nick = '';

    public function getNick() {
        return $this->nick;
    }

    public function setNick($p_nick) {
        $this->nick = $p_nick;
    }
}

En este ejemplo, vemos como un namespace puede tener sub-namespaces. "Model", es un sub-namespace dentro de "Users"

Una vez definida una clase en el namespace "Users\Model", podremos acceder a ella mediante otra clase, en este caso un controlador. Hay que recordar que, en caso de ser necesario hacer un include o un require, tendremos que hacerlo SIEMPRE después de la declaración del namespace.

namespace Users\Controller;
require_once 'users_model.php';

$bd = new \Users\Model\UserModel();
$bd->setNick('ZonaDev');

var_dump($bd->getNick());

En el caso de que la clase controlador y la clase modelo se encontraran en el mismo nombre de espacio, no haría falta añadir la ruta del nombre de espacio en la declaración.

También es interesante saber, que si vamos a utilizar mucho los objetos ubicados en un mismo namespace, podemos ahorrarnos bastante trabajo haciendo uso de la sentencia use, que además nos permite definir un alias para las clases. Aquí van algunos ejemplos:

namespace Users\Controller;
use Users\Model;
require_once 'users_model.php';

$bd = new UserModel();
$bd->setNick('ZonaDev');

var_dump($bd->getNick());

Usando alias:

namespace Users\Controller;
use Users\Model\UserModel as User;
require_once 'users_model.php';

$bd = new User();
$bd->setNick('ZonaDev');

var_dump($bd->getNick());

Con esta pequeña introducción a los namespaces, podremos entender mucho mejor el funcionamiento de los nuevos frameworks MVC que están saliendo y hacen uso de ellos, como es el ejemplo de Symfony2 y el inminente Zend Framework 2, además de motivarnos a utilizarlos para todo tipo de proyecto desarrollado en php.

Si quieres aprender más sobre el uso de namespaces, te recomiendo mirarte la documentación oficial de PHP en los siguientes enlaces:

Espacios de nombres (namespaces)
Usar espacios de nombres: Lo básico
FAQ: Cosas que se necesitan saber sobre los espacios de nombres

NOTA: Os recomiendo que leais el libro "Desarrollo web ágil con Symfony2" de Javier Equiluz, en el explica bastante bien que son los namespaces y como debemos utilizarnos (aplicando al entorno de Symfony2, claro).

CakePHP: Pros y contras (según mi opinión)

4 comentarios

Actualmente llevo ya más de 2 años trabajando con el Framework de CakePHP 1.2. No elegí yo trabajar con este framework, pero se me impuso en su día y al principio tengo que reconocer que me pareció una buena idea. Hasta ahora, que lo conozco bien y conozco sus mayores defectos (y seguro el de la mayoría de frameworks), por lo que en el futuro procuraré evitar cometer los mismos errores.

Voy a comentar mi punto de vista sobre el Framework, aunque tampoco me extenderé mucho. Empezaré por las ventajas.

PROS

  1. Fácil de aprender: Hay que reconocer que desarrollar con CakePHP es fácil y sencillo una vez te has documentado un poco y conoces la estructura de ficheros. Sin conocerlo de nada, en 2 días ya estaba creando mis primeras pantallas con el.
  2. Implementación rápida: Gracias a su estructura y los métodos propios del framework, desarrollar una aplicación puede realizarse en poco tiempo, eso si, en relación a si hubiera que hacerlo de 0, o si la aplicación no necesita modificaciones personalizadas.
  3. Migración entre entornos: Instalar una aplicación desarrollada con CakePHP es muy fácil, ya que  si tienes bien configurado el servidor en el nuevo entorno, bastará con copiar y pegar el código en el nuevo entorno. No necesita muchas librerías especiales, pero repito, depende de la aplicacuón y los componentes o plugins que se le añadan.
  4. Plugins: Mencionados en el punto anterior, se pueden encontrar por internet plugins que realizan una tarea específica sin tener que programar nada. Basta con bajarse el código y añadirlo a la carpeta de plugins de CakePHP. Lo mismo pasa con algunos "componentes" y "helpers".
Hasta aquí las ventajas más significativas que voy a comentar de CakePHP. Ahora pasaré a lo que para mi, es motivo suficiente como para no volver a utilizarlo en futuros proyectos:

CONTRAS
  1. Malos hábitos: En su documentación oficial, en algunos puntos te motivan a realizar algunos malos hábitos que deberían evitarse al trabajar con cualquier tipo de Framework MVC. Por ejemplo, con el método "find" de los modelos. Realizas la llamada desde el controlador, construyendo allí mismo la consulta, pero con el formato de CakePHP, enviando arrays. En mi opinión, todas las consultas find deben hacerse en el propio modelo, creando métodos allí que son los que realmente deben llamarse desde el controlador. Solo me pareció ver una referencia a esta forma de trabajar en la documentación de CakePHP, en uno de los últimos puntos de "recomendaciones", aunque ahora mismo tengo dudas. Además, con este sistema es mucho más sencillo poder cachear las consultas y queda el código mucho más limpio y ordenado. Ejemplo de llamada desde el controlador:
    $specificallyThisOne = $this->Article->find(
        'first', 
        array(
            'conditions' => array('Article.id' => 1)
        )
    );
    
  2. Exceso de consultas: En proyectos en los que el número de tablas es muy elevado y hay muchas relaciones, el ORM de CakePHP puede llegar a realizar excesivas consultas. En proyectos pequeños con pocas tablas esto no suele suceder o no suele ser tan importante, pero cuando hay más de 10 tablas esto puede ser un gran problema. La facilidad de CakePHP se compensa con su mal rendimiento en proyectos grandes. En CakePHP 2.0 dicen haber mejorado bastante el rendimiento, pero aún así el sistema de consultas es idéntico y sigue existiendo este mismo problema.
  3. Tamaño de ficheros: Algunos de los ficheros del propio Framework son demasiado pesados. Esto, añadiendo que hay demasiados ficheros del framework a los que se accede prácticamente en cada petición (request), conlleva a un elevado número de accesos al disco que penalizan el rendimiento del servidor, haciendo que el tiempo de carga de la web se eleve considerablemente. La única solución para esto utilizar un servidor que compile los ficheros PHP para agilizar esta tarea (Por ejemplo: Apache + APC).
Consejo
Antes de utilizar un framework para realizar una aplicación importante, de gran envergadura, documentate bien sobre los pros y los contras que tendrá ese Framework y si cumplirá tus expectativas a medio y largo plazo (a corto casi siempre lo hacen). Puedes verte obligado a tener que reescribir todo tu código si tomas una mala decisión o te pasas los pasos principales de todo desarrollo.
I+D, Análisis, desarrollo, guía de uso. Esto nunca debería faltar.


Reflexión personal.
¿Programadores?Esto ya es un problema más general de la informática en general, pero que lo aplicaré a CakePHP en este caso. En este mundillo, hay mucha gente que ha trabajado duro para realizar algunas aplicaciones, frameworks, o cms para facilitar las tareas a los que no son informáticos. El problema de esto es que muchos usuarios finales que no saben más que utilizar estas "facilidades" empiezan a creerse gurús. Cuidado con este tipo de gente, son muy peligrosos y están sueltos.