EstadoBeta

Descubriendo tus propios patrones en Ruby

Visita este artículo en http://www.estadobeta.com/2008/02/01/descubriendo-tus-propios-patrones-en-ruby/

Por Ismael en Patrones de diseño, Ruby & Rails, artículos, tips

Ejemplos y usos de Patrones de Diseño en Ruby.

Factories y Adapters, toma I

En el siguiente ejemplo, el usuario debe ser capaz de ingresar la dirección de un video en YouTube o una foto en Flickr a traves de un formulario. Mi aplicación debe ser capaz de usar adaptadores distintos para cada servicio y crear un objeto con los distintos formatos y tamaños de imán provistos por cada servicio. Por ejemplo:

Code (ruby)
 
recurso = ServiceFactory.instance( ‘Flickr’,'http://www.flickr.com/photos/ismasan/2224120921/’)
 
recurso.original #=> URL a la foto o video original
 
recurso.thumbnail #=> miniatura de foto o video

ServiceFactory es, como su nombre lo anuncia, una implementación de Factory, un patrón de Diseño muy común. Se usa cuando necesitas instancias de distintas clases según parametros variables. En nuestro caso, ServiceFactory.instance() es un método de clase que recibe el nombre de un servicio conocido (Flickr, YouTube, PhotoBucket, etc) y usa esa información para instanciar la subclase apropiada. Una implemntación simplista de esta Factory sería algo así:

Code (ruby)
 
class ServiceFactory
  # Metodo de clase para crear instancias
  # 
  def self.instance( service_name, url )
    subclass_name = "#{service_name}Adapter"
    subclass = const_get(subclass_name)
    subclass.new( url )
  end
 
  # Mas metodos a continuaci&oacute;n…
  # …
  def original
    # redefinido en cada subclase
  end
 
  def thumbnail
    # redefinido en cada subclase
  end
end
 

Esto significa que ServiceFactory.instance('Flickr','url_a_una_pagina_de_flickr...') nos entregará una instancia de la clase FlickrAdapter (que todavía no hemos definido). Es esta clase - similar a un “Adaptador”, otro Patrón de Diseño conocido - el que sabe cómo ir a la página de Flickr y rescatar la foto del HTML (posiblemente usando una combinación de la librería Net::HTTP y de expresiones regulares, o tal vez la excelente Gema Hpricot).

Code (ruby)
 
require ‘net/http’
class FlickrAdapter < ServiceFactory
  def initialize( url )
    @url = url
    process
  end
  
  # redefinimos original() y thumbnail() para rescatar los distintos tamanios de fotos de Flickr
  #
  def original
    # un poco de Expresiones Regulares
  end
 
  def thumbnail
    # otro poco de Expresiones Regulares
  end
 
  protected
  # Aqui se hace el trabajo pesado de ir a Flickr a buscar la foto
  #
  def process
     # Usar Net::Http para ir a @url a buscar la foto
  end
end
 

Los Adaptadores pueden tener toda la lógica interna que quieran, pero es importante que definan la misma interfaz. En este caso, todos los adaptadores deben definir los métodos original y thumbnail. De este modo tenemos una estructura básica para crear adaptadores para nuevos servicios.

Code (ruby)
 
video = ServiceFactory.instance( ‘YouTube’, ‘http://www.youtube.com/watch?v=3ydGP1QQHqw’ )
 
video.original # => URL del .FLV original
 
video.thumbnail # => URL de la imagen en miniatura del video
 
# Adaptador para YouTube
#
class YouTubeAdapter < ServiceFactory
  def initialize( url )
    @url = url
  end
  
  # redefinimos original() y thumbnail() para rescatar los distintos tamanios de fotos de Flickr
  #
  def original
    # …
  end
 
  def thumbnail
    # …
  end
 
  protected
  # etc etc
end
 

La ventaja de esta combinación de patrones es que los Adaptadores (no son realmente adaptadores, per llamemoslos así) son autónomos: otros programadores pueden escribir sus propios adaptadores sin preocuparse de cómo funciona toda la infraestructura, y sin necesidad de modificar la superclase. El único requisito es respetar la convención de nombres para las clases y la API (interfaz) de nuestro Adaptador. ServiceFactory podría ser encapsulado en una Gema y cada desarrollador escribe los adaptadores que necesita. Así es como funciona ActiveRecord y un inmenso número de librerías menos conocidas.

Rompiendo el patrón

Pero estos patrones no son nada nuevo y se vienen usando en el diseño de software desde eones*.

Nuestra aplicación está lejos de ser perfecta. Primero que nada, no sólo le exigimos al usuario que nos provea de la URL de su servicio en la Web, sino que también que nos indique de qué servicio se trata:

Code (ruby)
 
recurso = ServiceParser.instance( nombre_del_servicio, url_de_la_pagina )

Sería estupendo que bastara con la URL para adivinar el servicio. Al fin y al cabo, cada servicio tiene URL’s únicas. De este modo bastaría con que el usuario ingrese la URL en un formulario para que nuestro inteligente sistema sepa exactamente cómo manejarse (o avisarle al usuario si el servicio es desconocido).

Lo que podemo hacer definir Expresiones Regulares para cada URL y asignarlos al servicio correspondiente. Si la URL ingresada coincide con la expresión /flickr\.com/, por ejemplo, entonces sabemos que necesitamos una instancia de FlickrParser.

Esto complica nuestra Factory, que ahora debe buscar entre varias expresiones para encontrar el servicio adecuado.

Code (ruby)
 
SERVICIOS = {
  FlickrAdapter   => /flickr\.com/,
  YouTubeAdapter  => /youtube\.com/,
  PhotoBucketAdapter  => /photobucket\.com/
}
 
def self.instance( url )
    subclass = SERVICIOS.find(nil) {|klass, exp| url =~ exp} # retorna un array [clase, exp]
    raise "No existe un servicio para URL #{url}" if subclass.nil?
    subclass = subclass.first
    subclass.new( url )
end
 

Definimos una constante con un Hash de todos nuestros adaptadores y sus expresiones regulares correspondientes. Notese como usamos las clases mismas como llaves del Hash. En Ruby, las clases son también constantes y pueden ser usadas como llaves o pasadas como argumentos.

Nuestra Factory modificada recibe ahora una URL y busca en SERVICIOS hasta encontrar la subclase correspondiente. No tan complicado como pudo pensarse al principio.

Pero hay un problema que contraviene todas las normas básicas de OOP, uno que te condenaría al Fuego Eterno y 10.000 latigazos en el Infierno Geek.

La Super Clase no debe saber nada de las subclases.

Al definir la constante SERVICIOS en ServiceFactory, registrando todos los adaptadores existentes, estamos repartiendo conocimiento sobre las subclases en distintos lugares de nuestra aplicación. Esto es malo porque, cada que vez que queramos escribir un nuevo adaptador, nos vemos obligados a intervenir la infraestructura. Si imaginamos de nuevo que ServiceFactory es una Gema, tiene sentido pensar en un diseño que podamos extender en base a Adaptadores, sin necesidad de modificar la base.

Cómo podemos “registrar” las URL de cada servicio en la Factory, sin necesidad de intervenirla directamente?

Factories y Adapters, the Ruby Way

No hay nada en el Catálogo de Patrones de Diseño que nos indique cómo resolver este problema en particular. Es en este punto que tenemos que mirar más de cerca las capacidades de Ruby y aplicar un poco de ingenio.

Code (ruby)
 
class ServiceFactory
  # atributo de clase para registrar adaptadores.
  #
  @@adatpers = []
  
  # Accessor para array @@adapters
  #
  def self.adapters
    @@adapters
  end
 
  # …
end
 

ServiceFactory ahora se inicializa con un array, @@adapters (”@@” denota un atributo de clase, o “estático”). El método de clase self.adapters simplemente nos retorna ese array.

Ahora, cada subclase puede “registrarse” en la superclase, incluyendo su nombre y la expresión regular del servicio.

Code (ruby)
 
class FlickrParser < ServiceFactory
  ServiceFactory.adapters << [self, /flickr\.com/]
  
  #…
end
 
class YouTubeParser < ServiceFactory
  ServiceFactory.adapters << [self, /youtube\.com/]
  
  #…
end
 

Para esto aprovechamos otra particularidad del lenguaje: en Ruby todo el código se ejecuta al cargar en el intérprete, incluso las definiciones de clases. Esto significa que podemos llamar métodos y efectuar operaciones desde el cuerpo mismo de la clase. En este caso, agregamos un array con la subclase self y la expresión regular al atributo @@adapters de la Superclase ServiceFactory.

Code (ruby)
 
  ServiceFactory.adapters < < [self, /youtube\.com/]

Cuando todas las subclases se han registrado con la Superclase, necesitamos modificar ServiceFactory.instance() para usar este nuevo enfoque.

Code (ruby)
 
def self.instance( url )
    subclass = @@adapters.find(nil) {|klass, exp| url =~ exp} # retorna un array [clase, exp]
    raise "No existe un servicio para URL #{url}" if subclass.nil?
    subclass = subclass.first
    subclass.new( url )
end
 

Y ya está. Tenemos un diseño flexible, con un solo punto de entrada para nuestra API (ServiceFactory.instance()) y donde el conocimiento de cada servicio está adecuadamente encapsulado en las subclases o adaptadores. Ya podemos empaquetar nuestra Gema y anunciarla al mundo.

Un poco de elegancia

El ejercicio funciona, pero la llamada a ServiceFactory.register() es un poco fea. Con una última adición podríamos tener un pequeño DSL que hagan la creación de Adaptadores un poco m´s intuitiva. El objetivo es este:

Code (ruby)
 
class FlickrAdapter < ServiceFactory
  # DSL para registrarse con la Superclase
  # 
  register_url /flickr\.com/
end
 

Implementamos el método de clase register_url en la Superclase.

Code (ruby)
 
class ServiceFactory
  # usamos este metodo de clase en las subclases
  #
  # Opciones:
  # +exp+ una expresion regular
  #
  # cuando es llamado desde una subclase, "self" equivale a la subclase
  #
  def self.register_url( exp )
    ServiceFactory.adapters < < [self, exp]
  end
 
  # …
end
 

* O al menos desde que fue publicado el famoso Catálogo de Patrones de Diseño, más conocido como “GoF” (Gang of Four, en referencia a los 4 autores, a los 4 líderes de la China comunista y posiblemente al excelente grupo post-punk de los 80’s), en 1994.

Este artículo fue publicado en 1/2/2008 a las 7:43 am y está archivado bajo Patrones de diseño, Ruby & Rails, artículos, tips. Puedes seguir esta discusión a través de su canal RSS 2.0. También puedes enviarlo a Digg para compartirlo con más lectores. Puedes dejar un comentario, o hacer un trackback desde tu propio sitio.

7 comentarios para “Descubriendo tus propios patrones en Ruby”

carlos orrego Dice:
2/1/2008 at 11:31 am
mejor que usar al patrón de factory es usar algún framework de IOC o inversion of control. Te da una felxibilidad increible. Seguro que hay alguno implementado para Ruby.

saludos
carakan Dice:
2/1/2008 at 12:44 pm
Buen trabajo, yo personalmente aplicaba estos patrones dentro del lenguaje c#, pero veo que en ruby es bastante facil y compresible.
Saludos
Ismael Dice:
2/1/2008 at 1:29 pm
Carlos: si, hay un par que conozco (Needle y Copland), pero como dice el mismo autor de Needle (http://weblog.jamisbuck.org/2007/7/29/net-ssh-revisited), en realidad no son muy necesarios en Ruby debido a la flexibilidad del lenguaje. Si quieres “inyectar” nuevo comportamiento en una clase puedes incluso “reabrir” la clase y redefinir o ampliar cosas.

class Calculadora def suma(a,b) a + b end end
# Desde otra parte de tu codigo puede reabrir la clase! # class Calculadora # Hacemos un alias del metodo original para no perder su funcionalidad # alias :suma_original,:suma
# Redefinimos el metodo suma() # def suma(a,b) suma_original + 3 end end

Esto puede parecer demasiada fuerza bruta, pero esta flexibilidad se puede estructurar de mejor modo con tecnicas como el DSL de la ultima seccion de este articulo. En librerias como Rails este tipo de enfoque se usa por todos lados. Los plugins de ActiveRecord usualmente reabren o extienden las clases originales.
EstadoBeta » Archivo » Ruby class.inherited Dice:
2/25/2008 at 9:48 am
[…] mi artículo anterior explicaba cómo podemos usar la maleabilidad de Ruby para solucionar problemas espinosos. […]
EstadoBeta » Archivo » Incondicionalmente Dice:
3/18/2008 at 9:28 pm
[…] a aparecer entre tu código es hora de rediseñar tu aplicación (si digo eso una vez más en este blog tírenme tomates). Si tienes la fortuna de trabajar con OOP, ese rediseño […]
klara Dice:
5/30/2008 at 11:03 am
como puedo hacer una calculadora cientifica, q tenga todo lo q contiene la calcu cientifica mas metodos de simpson 1/3 3/8 y newton…. necesito ayuda xfiss
Rubén Dice:
1/2/2009 at 2:53 pm
Hola Ismael, una consulta sencilla ya que estoy en el aprendizaje de patrones, por que usar adapter y no strategy? Desde mi punto de vista strategy encaja mejor, ya que no es mas que una familia de algoritmos la que tienes ahi y todos implementan la misma interfaz.

Saludos.