PDF de programación - Clase 13. Patrones de diseño, 2ª parte

Clase 13. Patrones de diseño, 2ª parte.


3 Patrones de comportamiento

3.1 Comunicación multi-modos
Es bastante fácil para un único cliente utilizar una única abstracción. (Ya hemos visto
patrones para facilitar la tarea de modificar las abstracciones que están siendo utilizadas, lo
que es una tarea común). Sin embargo, en ocasiones, es posible que un cliente necesite utilizar
múltiples abstracciones; además de eso, tal vez el cliente no sepa con antelación cuántas o qué
abstracciones serán utilizadas. Los patrones observador (observer), cuadro negro
(blackboard) y mediador (mediator) permiten esta comunicación.

3.1.1 Observador
Suponga que existe una base de datos con todas las notas de los estudiantes del MIT, y el
personal docente del curso 6.170 desea consultar las notas de ese curso. Podrían escribir una
clase SpreadsheetView que mostrara la información de la base de datos. (Asumiremos
que el visor almacena en la caché los datos sobre los estudiantes del 6.170 – tal vez necesite
esa información para una nueva exhibición– aunque esto no es parte importante de este
debate). La visualización deberá tener un aspecto similar a esto:



Suponga que el código para comunicarse entre la base de datos que contiene las notas y la
visión de la base de datos utiliza la siguiente interfaz:


interface GradeDBViewer{
void update(String course, String name, String assignment,
int grade);
}


Cuando una nueva información sobre las notas está disponible (esto es, una nueva tarea es
calificada e introducida en la base de datos, o se vuelve a calificar una tarea cambiando la
nota antigua), la base de datos que contiene esas notas debe comunicar esa información al
visor. Vamos a suponer que Ben Bitdiddle solicitó una revisión del boletín de ejercicios 1, y
que esta revisión puso de manifiesto errores en las notas: la puntuación de Ben debería haber
sido 30. El código de la base de datos debe realizar llamadas a
SpreadsheetView.update. Suponga que lo hace de la siguiente manera:


SpreadsheetView ssv = new SpreadsheetView();
...
ssv.update(“6.170”, “B. Bitdiddle”, “PS1”, 30);


(Para simplificar, esta parte de código representa valores literales en vez de variables para los
argumentos de update.)


Entonces el aspecto de la plantilla electrónica sería la siguiente:



Tal vez el personal docente del curso decida más tarde que también le gustaría ver las medias
de las notas en un gráfico de barras e implementen el siguiente dispositivo visualizador:



Para mantener esta visualización conjuntamente con la visualización de la plantilla electrónica
es necesario modificar el código de la base de datos:


SpreadsheetView ssv = new SpreadsheetView();
BargraphView bgv = new BargraphView();
...
ssv.update(“6.170”, “B. Bitdiddle”, “PS1”, 30);
bgv.update(“6.170”, “B. Bitdiddle”, “PS1”, 30);


De la misma manera, añadir la visualización de un gráfico de tarta, o eliminar alguna
visualización, necesitaría de más modificaciones en el código de la base de datos. La
programación orientada a objetos (por no mencionar la buena práctica de la programación)
debe facilitar la realización de estas modificaciones: el código debe ser reutilizable sin
necesidad de editar o compilar de nuevo el cliente o la implementación.

El patrón observador logra el objetivo en este caso. En lugar de codificar de modo inmutable
qué visualizaciones actualizar, la base de datos puede mantener una lista de observadores que
sean notificados cuando su estado se altere.


Vector observers = new Vector();
...
for (int i=0; i<observers.size(); i++){

GradeDBViewer v = (GradeDBViewer) observers[i];

v.update(“6.170”, “B. Bitdiddle”, “PS1”, 30);
}

Para inicializar los vectores de los observadores, la base de datos facilitará dos métodos
adicionales, register para añadir un observador y remove para eliminar un observador.


void register(GradeDBViewer observer){

observers.add(observer);

}
void remove(GradeDBViewer observer){
return observers.remove(observer);

}


El patrón observador permite que el código de cliente (que gestiona la base de datos y los
dispositivos visualizadores) seleccione qué observador está activo, y los observadores pueden
incluso añadirse o eliminarse en tiempo de ejecución.

En este debate se han pasado por alto varios detalles. Por ejemplo, el cliente podría almacenar
toda la información que le interese (todas las notas del curso 6.170, o sólo las notas de
algunos estudiantes, o bien sólo el número de actualizaciones de la base de datos para
DatabaseActivityViewer), duplicando partes de la base de datos, o podría realizar una
lectura de la base de datos cuando sea necesario. Una decisión de diseño relacionada es si la
base de datos envía todos los datos potencialmente importantes para el cliente cuando tiene
lugar una actualización (éste es el modelo push), o la base de datos siempre informa al cliente,
“se ha realizado una actualización” (este es el modelo pull). El modelo push obliga al cliente a
solicitar información, lo que puede dar lugar a un mayor número de mensajes, pero en general
se transmite una menor cantidad de datos.

3.1.2 Blackboard
El patrón blackboard generaliza el patrón observador para permitir múltiples fuentes de datos
y múltiples visualizadores. También realiza un completo desacoplamiento de los productores
y consumidores de información.

Blackboard es un almacén de mensajes que puede ser leído y editado por todos los procesos.
Siempre que ocurra algo que puede ser de interés para otra parte, el proceso responsable o
informado sobre el evento añade al blackboard una notificación del evento. Otros procesos
pueden leer el cuadro negro. En un caso típico, ignoran la mayoría de su contenido, que no les
es de interés, sin embargo, tal vez reaccionen a otros eventos. Un proceso que coloca una
notificación en el blackboard no sabe si cero, uno, o varios otros procesos están prestando
atención a sus modificaciones.

Estos patrones, por lo general, no imponen una estructura determinada a sus anuncios, pero es
necesario un formato de mensaje bien comprendido para que los procesos puedan operar entre
sí. Algunos presentan servicios de filtro para que los clientes no vean todas las
modificaciones, sino sólo las de un tipo determinado; otros envían notificaciones
automáticamente para los clientes que tengan interés registrado (ésta es una técnica pull).

Un boletín de noticias ordinario (tanto físico como electrónico) es un ejemplo de un sistema
que emplea un blackboard. Otro ejemplo que emplea este patrón en el MIT es el servicio de
mensajes zephyr.


El texto de Liskov llama a este patrón “white board” en lugar de “blackboard”. El primer
nombre tiene una apariencia más moderna, pertenece a la terminología de computación
estándar que lleva utilizándose durante décadas y se reconocerá mejor fuera del curso 6.170.
El primer gran sistema que empleó el patrón blackboard fue el sistema de reconocimiento del
habla Hearsay-II, implementado entre 1971 y 1976.

3.1.3 Mediador
El patrón mediador es un patrón intermediario entre observador y blackboard. Desacopla las
informaciones de los productores y de los consumidores, pero no desacopla el control.
Mientras que la comunicación del patrón blackboard es asíncrona, en el patrón mediador es
síncrona: no devuelve el control a los productores antes de pasar la información a todos los
consumidores.

3.2 Conexión de compuestos
Consultar sección 4.2 sobre el patrón de diseño composite. Esta sección trata de cómo
conectar compuestos o realizar otras operaciones en todas las subpartes de un compuesto.
Nuestro objetivo es que sea capaz de funcionar en varias operaciones diferentes, y ser capaz
de realizarlas en varias subpartes de un objeto compuesto. Como tanto la operación a realizar
como el tipo de objeto compuesto en el que la operación será realizada afectan a la
implementación, decidir cómo dividir el problema en partes puede ser difícil.

Piense en el ejemplo de un árbol de sintaxis abstracta, o AST, que es una representación de
(la sintaxis de) un programa de computación. Por ejemplo, el operador de adicción binaria +
puede estar representado por objetos:


PlusOp:
class PlusOp extends Expression {

Expression leftExp;
Expression rightExp;

Las referencias variables, las operaciones de distribución (a=b), y las expresiones
condicionales (a?b:c) son otro tipo de expresiones:


...
}


...
}

VarRef lvalue; // lado izquierdo; “a” en “a=b”
Expression rvalue; // lado derecho; “b” en “a=b”

class VarRef extends Expression {
String varname;
...
}
class AssignOp extends Expression {

...
}
class CondExpr extends Expression {

Expression condition;
Expression thenExpr;
Expression elseExpr;

Una representación completa tendría también muchos otros tipos de nodos AST, como
AssignOp para atribuciones, para expresiones, etc.


Un uso particular de +, como a + b, sería representado en tiempo de ejecución por



Objetos


Un compilador u otra herramienta de análisis de programas crea un AST analizando
sintácticamente el programa destino; tras el análisis, la herramienta realiza operaciones, como
la verificación de tipos (typecheck), estilo de impresión (pretty-printing), la optimización o la
generación de código, en el AST. Cada operación difiere de las otras, pero cada nodo AST es
también distinto de los otros.

Cada célula de esta tabla se rellenará con un código diferente:



Operaciones


La cuestión es si organizar el código de manera que se reúna todo el código de verificación de
tipo (y necesariamente ampliar el código relativo a CondExprs por la implementación) o
agrupar todo el código que se ocupa de un tipo particular de expresión, pero separar el código
que versa sobre una operación particular.

(Un asunto parecido es cómo seleccionar y ejecutar el bloque de código adecuado,
independi