PROCESOS DE RAZONAMIENTO INVERSO: PATRÓN DE DISEÑO ADAPTER EN PYTHON Y PHP, LOS

Transcripción

1 10 PROCESOS DE RAZONAMIENTO INVERSO: PATRÓN DE DISEÑO ADAPTER EN PYTHON Y PHP, LOS CÓMO Y LOS PARA QUÉ TIENES UN ENCHUFE DE TRES PATAS PERO UN TOMA CORRIENTE DE DOS. NECESITAS INSERTAR LA CLAVIJA EN EL TOMA SIN MODIFICAR NINGUNA DE LAS DOS. SOLUCIÓN: UTILIZAS UN ADAPTADOR. BIENVENIDAS/OS AL PATRÓN DE DISEÑO ADAPTER. Necesitaba un ejemplo sencillo que me permitiese demostrar visualmente, cómo funciona el patrón de diseño Adapter y el ejemplo del enchufe, me vino «como anillo al dedo». Pues no podría ser más claro: es la imagen perfecta e inequívoca para comprender este maravilloso patrón de diseño. En la programación orientada a objetos, un patrón de diseño representa la forma en la cual se puede resolver el comportamiento de un objeto o la relación entre ellos y el patrón de diseño Adapter (adaptador) resuelve la necesidad de conectar dos (o más) objetos entre sí, dónde al menos uno de ellos necesitaría ser modificado. Pero para poder explicarlo sin riesgo a confusiones, me voy a valer de un caso real. Para ello, les pido que imaginemos que tenemos un típico objeto Usuario: # La clase Usuario en PHP class Usuario { $this->usuario_id = 0; $this->nombre = ''; # La clase Usuario en Python class Usuario(object):

2 11 def init (self): self.usuario_id = 0 self.nombre = '' Y nos encontramos con que debemos implementar las siguientes Historias de Usuario: Cómo usuario puede enviar mensajes a otro usuario del sistema Cómo usuario puedo ver una lista de los mensajes que he recibido desde otros usuarios Hablamos de un requerimiento típico de una gran parte de las aplicaciones tanto Web como de escritorio. Si simplemente pensáramos en DATOS pero NO EN OBJETOS, nos encontraríamos con una tabla de mensajes, con un campo remitente_id, otro destinatario_id, y otros más destinados a almacenar la fecha, el asunto y el cuerpo del mensaje, por ejemplo. Y lo anterior, arrojaría como resultado una clase con propiedades simples y complicados y errados métodos no estándar, que realicen consultas cruzadas en la base de datos: SELECT FROM mensaje.mensaje_id, mensaje.asunto, mensaje.cuerpo, mensaje.fecha, mensaje.estado, usuario.nombre AS remitente, usuario.nombre AS destinatario mensaje INNER JOIN usuario ON mensaje.remitente_id = usuario.usuario_id OR mensaje.destinatario_id = usuario.usuario_id etc. Y luego la clase Mensaje derivaría del diseño previo de la base de datos: class Mensaje(object): def init (self): self.mensaje_id = 0 self.asunto = '' # self.remitente_id = 0 # Usuario.usuario_id self.destinatario_id = 0 # también sería Usuario.usuario_id Lo anterior, sería un ejemplo sobre cómo las malas costumbres nos llevan a pensar en datos. Pero sin embargo, podríamos pensar estrictamente en objetos y en este caso, nos encontraríamos con la siguiente definición inicial del objeto mensaje: El mensaje tiene 1 remitente El mensaje tiene 1 destinatario

3 12 Esto, nos haría deducir, correctamente, que Remitente y Destinatario, serían dos tipos de objetos diferentes: class Remitente { class Destinatario { class Remitente(object): class Destinatario(object): Y a la vez, Mensaje, tendría dos propiedades compuestas por los objetos Remitente y Destinatario respectivamente: class Mensaje { function construct(remitente $rtte=null, Destinatario $dest=null) { #... $this->remitente = $rtte; $this->destinatario = $dest; #... class Mensaje(object): def init (self, remitente=none, destinatario=none): #... self.remitente = compose(remitente, remitente) self.destinatario = compose(destinatario, remitente) # notar que he utilizado una función llamada compose(objetorequerido, objeto_compositor) # cuyo fin sería el de componer a la propiedad # para más información, se puede leer sobre el patrón de diseño compuesto en Python # en Sin embargo, no necesitamos siquiera, analizar a los objetos Remitente y Destinatario en profundidad, para saber que en realidad estamos hablando de objetos Usuario: class Remitente extends Usuario { class Destinatario extends Usuario { class Remitente(Usuario):

4 13 class Destinatario(Usuario): Hasta aquí, nada parece complicado. Sin embargo, los objetos Remitente, Destinatario y Usuario, son exactamente iguales. Entonces por qué no componer Mensaje directamente con el objeto Usuario? La razón es sencilla y es que en la orientación objetos bien implementada, las propiedades compuestas llevan el nombre del objeto que las compone y eso permite: Obtener objetos más reales, relacionalmente lógicos y estructuralmente coherentes; Lograr una mayor legibilidad y facilidad de comprensión; No ensuciar los métodos constructores con funciones destinadas a manejar el tipo de datos de las propiedades; Utilizar mapeadores relacionales de objetos (ORM) basados en objetos reales y no en parches de datos colocados a los objetos. Entonces, repasando, hasta aquí tendríamos los siguientes objetos y relaciones: Diagrama UML realizado con Dia (Software Libre) Pero lo cierto es, que tanto Remitente como Destinatario son objetos simulados, creados para satisfacer las exigencias del objeto Mensaje. Y en realidad, cuando el método get() de Mensaje sea invocado y éste, intente componer sus dos propiedades (Mensaje.remitente y Mensaje.destinatario), el método get() real al que debería invocarse, tendría que ser el método get() de Usuario, ya que a decir verdad, es el verdadero compositor. Mensaje debería recurrir al método get() de Usuario que es el verdadero compositor

5 14 Aquí es dónde la adaptación real sale a la luz. Remitente y Destinatario al fin deberán adaptar las clavijas de Usuario para ser insertadas en el toma corriente de Mensaje. Es entonces cuando la función transformadora de ambos objetos, pasa a ser la adaptación del método get() de Usuario: Cuando Mensaje llame al método get de Remitente y Destinatario, en realidad deberá ser el método get de Usuario quien deba ejecutarse y luego, transformar a Usuario en un Remitente y en un Destinatario respectivamente. Remitente y Destinatario, deberán entonces, sobrescribir el método get heredado de Usuario, a fin de que Usuario.get() sea llamado, cada vez que Remitente.get() y Destinatario.get() sean invocados: $usuario = new Usuario(); $usuario->usuario_id = $this->usuario_id; $usuario->get(); foreach($usuario as $property=>$value) { $this->$property = $value; def get(self): usuario = Usuario() usuario.usuario_id = self.usuario_id usuario.get() for property, value in vars(usuario).iteritems(): setattr(self, property, value) Incluyendo esta sobre-escritura del método get() de Usuario, Remitente y Destinatario se transforman en dos adaptadores. Y sería genial, si no existiese la redundancia, pues el método get() se sobrescribe igual en Remitente que en Destinatario y uno de los principios del Refactoring indica que: Si dos clases que heredan de la misma clase tienen métodos idénticos, se extrae el método repetido y se lo lleva a la clase Madre Pero qué sucedería si este método fuese llevado a la clase madre? Claramente, estaríamos eliminando el verdadero método get() de Usuario. Entonces, la solución es extraer el método hacia una nueva clase y hacer heredar a Remitente y destinatario de esta nueva clase. Y ésta, a la vez, sería quien herede de Usuario: class UsuarioAdapter extends Usuario {

6 15 $usuario = new Usuario(); $usuario->usuario_id = $this->usuario_id; $usuario->get(); foreach($usuario as $property=>$value) { $this->$property = $value; class Remitente extends UsuarioAdapter { class Destinatario extends UsuarioAdapter { class UsuarioAdapter(Usuario): def get(self): usuario = Usuario() usuario.usuario_id = self.usuario_id usuario.get() for property, value in vars(usuario).iteritems(): setattr(self, property, value) class Remitente(UsuarioAdapter): class Destinatario(UsuarioAdapter): AVISO: notar que en los ejemplos no se ha utilizado el método constructor en las clases, no porque no deba utilizarse (al contrario), sino porque no es de relevancia para el ejemplo. Finalmente, la relación quedaría como la siguiente:

7 16 PATRÓN DE DISEÑO ADAPTER EN EUROPIO ENGINE Si estás utilizando Europio Engine ( habrá que tener en cuenta que al momento de invocar al método get() de Mensaje, cuando éste recurra al get() de Remitente y Destinatario para componer sus dos propiedades homónimas, el ORM considerará las propiedades remitente_id y destinatario_id, como las propiedades identificadoras de Remitente y Destinatario respectivamente. Lo propio sucederá con la propiedad id de UsuarioAdapter. Por lo tanto, habrá que agregar a Remitente, Destinatario y UsuarioAdapter, sus respectivas propiedades ID y encargarse de asignarles el valor necesario: class Remitente extends UsusarioAdapter { parent:: construct(); $this->remitente_id = 0; $this->usuario_id = $this->remitente_id; parent::get(); class Destinatario extends UsusarioAdapter { parent:: construct(); $this->destinatario_id = 0; $this->usuario_id = $this->destinatario_id; parent::get(); class UsuarioAdapter extends Usuario { $this->usuarioadapter_id = $this->usuario_id; $usuario = new Usuario(); $usuario->usuario_id = $this->usuario_id; $usuario->get(); foreach($usuario as $property=>$value) { $this->$property = $value;