Este artículo ha sido consultado en 846 ocasiones.

Patrones de diseño en Python

Vespe Savikko

Software Systems Laboratory
Tampere University of Technology
FIN-33101 Tampere, Finland
vespe@cs.tut.fi

Traducido por Iván Márquez Larios
ivanjose@gmail.com

Sinopsis

La elección del lenguaje con el que se implementará afecta el uso de los patrones de diseño.  Naturalmente algunos lenguajes aplican mejor que otros para distintas tareas.  Cada lenguaje tiene su propio conjunto de fuerzas y debilidades.  En este ensayo implementamos algunos de los patrones de diseño más comunes en Python, cuyo modelo de objetos es bastante distinto al de los lenguajes orientados a objetos convencionales.  Por lo tanto, conseguimos algo de visión interna de los patrones en el contexto de Python.

1. Introducción

2 Python

La otra característica sobresaliente de los objetos de Python es que no son meramente instancias de sus clases; sus estructuras pueden cambiar en tiempo de ejecución.  Este nivel de flexibilidad combinado con la habilidad de la instancia de atrapar el acceso a los atributos finca las bases para varios idiomas de python.  Por otro lado también requiere de algun control del programador, porque demasiado código "dinámico" puede ser bastante difícil de entender y mantener.  Esto aplica también para los programas de Python en general; mientras que el lenguaje hace fácil realizar tareas relativamente complejas, no nos alivia a los programadores de las demandas de los principios de diseño.

3 Singleton

class Singleton {



public:

  static Singleton& Handle();

  

private:

  static Singleton* psingle;

  Singleton();

  Singleton( const Singleton& );

  Singleton& operator=( const Singleton& );

};      

Nuestra definición mínima de un singleton (Fig. 1) tiene solo un miembro público: el método manejador de la clase Handler.  La interfaz definida no es muy útil comotal, porque el cliente no puede hacer nada con la instancia, pero ahoranos concentramos solo en las técnicas que aseguran una solainstancia del singleton a la vez.

El constructor privado prohibe la creación de un objeto fuera de laclase.  Por ende los clientes de la clase tienen que dependeren la función miembro estática:ya sea que estacree una nueva instancia o devuelva una referencia al objeto singleton(Fig. 2 ).

Singleton& Singleton::Handle() { 
if( !psingle ) {
psingle = new Singleton;
}
return *psingle;
} 

Ya que Python no tiene constructores privados debemos encontrar una alternativa para prevenir instanciaciones.  Nuestra aproximación en la figura 3 es para lanzar una excepción si el objeto singleton ya se encuentra instanciado (el atributo privado de la clase __single es distinto de None).  ¡El objeto excepción es la instancia singleton!  La desventaja de esta solución es que requiere que los clientes estén preparados para la excepción. También podría ser argumentado que utilizar excepciones para otros propósitos distintos del manejo de errores no es un muy buen estilo.  Estas consideraciones pueden ser eliminadas hasta cierto punto proveyendo un manejador similar al de la figura 2.  Esta función oculta los detalles de la instanciación poco ortodoxa y devuelve una referencia al objeto singleton (Fig. 4).

class Singleton:
    __single = None
    def __init__( self ):
       if
Singleton.__single:
           raise
Singleton.__single
       Singleton.__single
= self    

Debido al sistema de tipos de Python el código en la figura 4 funciona para toda la jerarquía singleton.  Consideremos la siguiente situación: la clase Singleton tiene sublcases Child y Junior como se muestra en la figura 5.  Debido a que existe una relación es-un entre la clase base y la subclase solamente puede haber una instancia de toda la jerarquía. Una instancia de Singleton o Junior puede ser creada con la función Handle.  El constructor de la clase toma un parámetro -explícito- para que la instanciación deba ser hecha con una llamada directa al constructor o a una función especializada de manejo.  El siguiente código demuestra la jerarquía Singleton:

>>> child = Child( 'Monty' )
>>> junior = Handle( Junior )
>>> junior.name()
'Monty'
>>> single = Handle()
>>> single
<Child instance at d1d88>  

Afortunadamente la simplificación es posible a través de los conceptos de domino de nombres de Python.  Los ámbitos local y global - o en su defecto su representación de diccionario - pueden ser accedidos por funciones locales y globales.  Por ejemplo podríamosinstanciar Junior:

>>> name = 'Junior'
>>> sclass = globals()[name]
>>> junior = Handle( sclass )
>>> junior
<Junior instance at d1bd8>

Tal vez la solución más segura y directa es la de registro en el nivel del módulo.  Cada módulo que contenga clases Singleton deberían también contener sentencias de inicialización que registren los nombres de las clases con el módulo de registro. Debido a que los módulos son inicializados sólo la primera vez que son importados, un cliente obtiene acceso al registro importando el módulo del registro.  En cierto modo un módulo puede ser visto como un Sigleton rudimentario.  Una ventaja de este estilo de registro explícito es la opción de implementar tantos registros sofisticados como sean necesarios.  En otras palabras podremos almacenar más información acerca de los singleton que solo los nombres de las clases, por ejemplo los nombres de los módulos, diferentes restricciones y así.  El registro puede también ofrecer diferentes servicios para las búsquedas de singleton, estadísticas y depuración, por ejemplo.

def Handle( x = Singleton ):

    try:

       single
= x()

    except Singleton, s:

       single
= s

    return
single   

class Child( Singleton ):
    def __init__( self, name ):
       Singleton.__init__(
self )
       self.__name
= name
    def name( self ):
       return
self.__name
class Junior( Singleton ):
    pass    

4 Cadena de responsabilidad

Un patrón de cadena de responsabilidad es a menudo utilizado en el contexto de interfaces gráficas de usuario donde un objeto puede contener varios otros objetos.  Como el ambiente de ventanas genera eventos los objetos o los manejan o los pasan a su objeto padre(contenedor), como en la figura 6.

Figura 6. Una jerarquía simple de ventanas

Si MsgText recibe unevento su método Handle o maneja el evento o llama almétodo Handle de SendDialog, y así sucesivamente.   MsgText no necesita saber qué objeto - si lo hay - manejará el evento; la jerarquía no tiene que ser preparada.  En otrocontexto un objeto MsgText podría comportarse similarmente y así las jerarquías pueden ser modificadas en tiempo de ejecución.  La jerarquía no requiere necesariamente ser en forma de árbol.  Una variación del patrón podría ser un sistema en el que los objetos crearan una estructura estilo anillo y algunos o todos los objetos pudieran actuar como clientes así como parte de la cadena.

La implementación del patrón en C++ es relativamente directa: en nuestro ejemplo de GUI cada objeto podría ser una subclase de la clase Widget definida en la figura 7. Mientras que esto es también una solución alcanzable en Python, no utiliza el modelo de objetos de Python a su potencial máximo.  Una aproximación más dinámica y flexible es utilizar las técnicas introducidas en el patrón de despacho de comandos de Guido van Rossum [vR97]: búsqueda y adición dinámica de atributos.

class Widget {

public:
 Widget( Widget* pw ): pwParent( pw ) {}
 virtual void Handle( Event );
private:
 Widget* pwParent;
}; 

Con Python no necesitamos restringirnos al conjunto predefinido de métodos como lo hicimos con la jerarquía Widget: el único camino para manejar este evento era llamando a Handle.  La idea detrás del patrón de despacho de comando es checar en tiempo de ejecución si el objeto tiene un método propio o no.  Nuestra clase Widget en Python(Fig. 8) provee a sus subclases con este mecanismo de despacho.  El uso de clases evento separadas (Event en la figura 8) enfatiza el hecho de que varias clases de información pueden ser transmitidas a través dela cadena.  Solamente el atributo name es asumido. Dado que nuevos atributos pueden ser añadidos dinámicamente y nuevos métodos pueden ser agregados a traves de sublcases, la interface de la clase base Event puede ser mantenida al mínimo.

class Event:
 def __init__( self, name ):
 self.name = name

class Widget:
 def __init__( self, parent = None ):
 self.__parent = parent
 def Handle( self, event ):
 handler = 'Handle_' + event.name
 if hasattr( self, handler ):
 method = getattr( self, handler )
 method( event )
 elif self.__parent:
 self.__parent.Handle( event )
 elif hasattr( self, 'HandleDefault' ):
 self.HandleDefault( event ) 

Cuando un objeto evento es pasado al método Handle, una de cuatro cosas pueden pasar:

1.

Cada evento tiene su nombre asociado. Si Widget tiene un método correspondiente (llamado Handle_nombreevento), es ejecutado.

2.

Si el objeto no es el último de lacadena, pasa el objetoevento a su padre.

3.

Si el objeto tiene un manejador por defecto para toda clase de eventos(método HandleDefault) es invocado si el objeto es el último manejador posible.  Ya que HandleDefault debe siempre estar disponible sólo al final de la cadena, no es necesario ni recomendable tenerlo en la interface de la clase base.

4.

El objeto ignora el evento si no lo puede manejaro reenviar.

class MainWindow( Widget ):
 def Handle_close( self, event ):
 print 'MainWindow: ' + event.name
 def HandleDefault( self, event ):
 print 'Default: ' + event.name
 
class SendDialog( Widget ):
 def Handle_paint( self, event ):
 print 'SendDialog: ' + event.name

class MsgText( Widget ):
 def Handle_down( self, event ):
 print 'MsgText: ' + event.name

Algunas clases Python para nuestro GUI de ejemplo son implementadas en la Figura 9.  El siguiente código construye la cadena y demuestra su uso:

>>> sd = SendDialog( mw )
>>> msg = MsgText( sd )
>>> edown = Event( 'down' )
>>> msg.Handle( edown )
MsgText: down
>>> epaint = Event( 'paint' )
>>> msg.Handle( epaint )
SendDialog: paint
>>> eodd = Event( 'odd' )
>>> msg.Handle( eodd )
Default: odd

... print 'Name: ' + e.name
... 
>>> sd.Handle_odd = PrintName
>>> msg.Handle( eodd )
Name: odd
>>> del sd.Handle_odd
>>> msg.Handle( eodd )
Default: odd

5 Proxy

Desde la perspectiva del diseño orientado a objetos la habilidad para atrapar accesos a atributos provee algunas nuevas soluciones a viejos problemas.  Un buen ejemplo es el patrón Proxy, el cual es utilizado cuando un objeto tiene que ser escudado de sus clientes.  Puede haber varias razones para ello: conteo de referencias, distintos niveles de permisos de acceso,evaluación floja del estado de un objeto y otras. La estructura del objeto en tiempo de ejecución para el patrón es mostrada en la figura 10.  

Figura 10. Estructura del objeto en tiempo de ejecución

El cliente no necesita saber que no está accediendo al objeto real(Subject) directamente.  En otras palabras, el proxy substituye al objeto real.  En C++ esto podría significar que ambos, el proxy y la clase sujeto tienen una clase común de base.  En Python el mismo efecto puede ser logrado enmascarando la instancia del proxy como el objeto proveyendo la misma interface de métodos.  Nuestra clase proxy en la figura 11 está basada en la clase cuasiuniversal Wrapper [vR96].  Como tal, la clase Proxy es sólo una envolvente trivial para cualquier objeto. Sin embargo, su función principal es la de servir a su clase base para implementaciones más específicas.  Dado que el método __gettattr__ es llamado sólo como el último recurso el proxy puede manejar un método sujeto diferentemente "sobrecargándolo" en la claseproxy. Consideremos la siguiente situación: accedemos una instancia de la clase RGB (Fig. 12) primero directamente, luego utilizando una instancia de Proxy genérica como una envolvente y finalmente a través de una instancia de NoBlueProxy (Fig. 13):  

>>> rgb = RGB( 100, 192, 240 )
>>> rgb.Red()
100
>>> proxy = Proxy( rgb )
>>> proxy.Green()
192
>>> noblue = NoBlueProxy( rgb )
>>> noblue.Green()
192
>>> noblue.Blue()
0

class Proxy:
 def __init__( self, subject ):
 self.__subject = subject
 def __getattr__( self, name ):
 return getattr( self.__subject, name ) 

class RGB:
 def __init__( self, red, green, blue ):
 self.__red = red
 self.__green = green
 self.__blue = blue
 def Red( self ):
 return self.__red
 def Green( self ):
 return self.__green
 def Blue( self ):
 return self.__blue 

class NoBlueProxy( Proxy ):
 def Blue( self ):
 return 0 

Mientras que python provee algunos mecanismos que son usualmente implementados con el patrón Proxy (por ejemplo el conteo de referencias simples)el patrón es todavía altamente aplicable a la comunidad Python.  Un excelente ejemplo es el paquete deDaniel Larsson RemoteCall [Lar97], que provee un mecanismo simple para aplicaciones distribuidas.  Uno de los conceptos clave en el sistema es el rol de agente, el cual es una representación del lado del cliente de los objetos del lado del servidor - en otras palabras, proxies.  La historia del paquete también demuestra un aspecto digno de mencionar de los patrones en general: el autor reconoció que había aplicado un patrón después después de su implementación.

6 Conclusiones

El uso de Python como un lenguaje de implementaciones puede también reforzarel patrón.  La naturaleza flexible y dinámica del lenguaje provee una buena base para una variedad de distintas y elegantes soluciones.  Nuestra cadena de responsabilidad hace el patrón más dinámico al implementarlo con el patrón despacho de comandos, el cual toma ventaja de las capacidades de Python en tiempo de ejecución.  Estas capacidades incluyen búsquedas y adiciones de atributos en tiempo de ejecución.  En otras palabras, las instancias de una misma clase no necesariamente requieren tener estructura idéntica y el acceso a los atributos puede ser monitoreado y atrapado.  Estos mecanismos proveen una forma bastante elegante de implementar varias clases genéricas como en nuestra implementación del Proxy.

Elegimos tres patrones para enfatizar los problemas discutidos, pero tenemos la confianza de que otros patrones del GOF pueden ser implementados en Python, y con resultados similares.  Mientras que los patrones pudieran terminar con características flexibles y dinámicas después del proceso, no necesariamente erosionaría la usabilidad y reconocibilidad de los patrones.  La familiaridad y el orden provisto por el uso de patrones puede ofrecer mayores beneficios para diversos sistemas de objetos y frameworks Python.

Referencias

BMR+96

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, and Michael Stal.
Pattern-Oriented Software Architecture -- A System of
Patterns.
John Wiley & Sons, 1996.
457 pages.

Dub96

Paul Dubois.
Introduction to Python .
Tutorial at TOOLS USA 96, August 1996.

GHJV95

Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides.
Design Patterns -- Elements of Reusable Object-Oriented
Software.
Addison-Wesley, 1995.
395 pages.

Lar97

Daniel Larsson.
RemoteCall package.
http://www.python.org,
September 1997.

Lun97

Fredrik Lundh.
Singleton Pattern .
Python Pattern-SIG mailing list, July 1997.
http://www.python.org.

vR96

Guido van Rossum.
Python Tutorial, October 1996.
http://www.python.org.

vR97

Guido van Rossum.
Command Dispatch Pattern .
Python Pattern-SIG mailing list, May 1997.
http://www.python.org.

Última actualización: 2007-04-29 10:56:59-05

teosho está:
Preparandome para el viaje a Puerto Vallarta... que triste...
1 hour, 22 minutes ago

scarecrow está:
Du hast?
5 hours, 25 minutes ago

der_teufel está:
Ich habe einen Kater, aber nicht so schlecht...
13 hours ago

rnstux está:
Y yo un Abrazo.
1 day, 12 hours ago

saidjose está:
Dandole su habrazote a mi santa madre que me soporta
1 day, 14 hours ago

dsquid está:
esperando a que este el pozole
1 day, 16 hours ago

Que estuvimos haciendo >>

Consultoría y Soporte