Objetos y mensajes

Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
2. Los pilares: objetos, mensajes y ambigüedad
Índice
2. Los pilares: objetos, mensajes y ambigüedad ............................................................. 35
Sobre el capítulo ..................................................................................................... 36
Motivaciones ...................................................................................................... 36
Objetivos............................................................................................................. 36
Contenidos .......................................................................................................... 36
2.1 Conceptos básicos del software OO ..................................................................... 37
2.2 La globalidad de los atributos de un objeto .......................................................... 38
2.3 Visibilidad de los atributos y operaciones ............................................................ 39
2.4 Representación gráfica ......................................................................................... 40
Objeto ................................................................................................................. 40
Mensaje............................................................................................................... 40
Intercambio de mensajes .................................................................................... 41
Diagrama de secuencias...................................................................................... 41
Diagrama de colaboración .................................................................................. 44
2.5 Ejemplo de diseño. Control de acceso .................................................................. 46
La tarea ............................................................................................................... 46
El diseño del sistema .......................................................................................... 46
Diseño del mecanismo de aceptación ................................................................. 47
Criterios de diseño .............................................................................................. 48
Objetivos y beneficios ........................................................................................ 48
Inconvenientes .................................................................................................... 49
Diseño del mecanismo de rechazo...................................................................... 50
Reflexiones sobre el diseño del sistema ............................................................. 51
2.6 Refactorización ..................................................................................................... 52
2.7 Encapsulado y principio de ocultación, una confusión frecuente ........................ 53
2.8 Un paso hacia el principio de ocultación de información .................................... 54
Concentrar la tarea .............................................................................................. 55
De nuevo, otra forma de pensar .......................................................................... 56
2.9 La incertidumbre como solución .......................................................................... 57
2.10 La ambigüedad es la clave .................................................................................. 59
Influencia favorable sobre facilidad de desarrollo y modificación .................... 59
Relación ambigua ............................................................................................... 61
Relación unívoca ................................................................................................ 61
Influencia sobre el significado del diseño .......................................................... 62
Bibliografía ............................................................................................................. 64
35
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Sobre el capítulo
Motivaciones
El capítulo anterior fue una primera aproximación al universo de los objetos que
pretendía resaltar su forma particular de pensar el software y la diferencia radical con el
enfoque estructurado de funciones y datos. Pero aun queda mucho camino por andar. El
terreno todavía es confuso. Hay que profundizar en los pilares: los objetos, los mensajes
y la ambigüedad. Los dos primeros son las piezas primarias y la ambigüedad es la guía
para conseguir los beneficios del enfoque de objetos. El diseño es el fin y el medio que
armoniza todas estas ideas.
Objetivos
El objetivo del presente capítulo es que los alumnos comprendan:
1. Los conceptos básicos: objetos, mensajes y sus propiedades.
2. La notación gráfica.
3. Criterios de diseño.
4. El papel de la ambigüedad como herramienta de diseño.
Contenidos
La primera parte se dedica a estudiar con detalle los conceptos y cualidades del
universo de objetos y mensajes.
La segunda, se ocupa de describir la notación estándar (UML) que se utiliza para
expresar un diseño en términos de objetos y mensajes.
La tercera parte, utiliza un diseño como medio para estudiar criterios de diseño y
las ideas confusas alrededor de este tema. El eje central es la ambigüedad como
herramienta de diseño.
36
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
2.1 Conceptos básicos del software OO
Los dos conceptos básicos de la orientación a objetos son objeto y mensaje.
Objeto: es una variable software con capacidad para ejecutar operaciones. Por
ejemplo, los objetos círculo1 y círculo2 son variables software capaces de pintar
el círculo que definen. Los objetos se pueden crear y destruir durante la
ejecución del programa. Desde el punto de vista conceptual un objeto software
es una cosa; un elemento de mucha ambigüedad.
Mensaje: es la solicitud a un objeto para que ejecute una operación. Por
ejemplo, círculo1.Pintar es un mensaje dirigido al objeto círculo1 para que se
pinte. La estructura de cualquier mensaje es [objeto][separador][operación]. En
el ejemplo, “círculo1” es el objeto, “.” es el separador y “Pintar” es la
operación. Como un mensaje está dirigido a una variable, también es un
elemento de elevada ambigüedad.
Estos dos conceptos son necesarios y suficientes, es decir esenciales, para
construir un modelo orientado a objetos. Las clases y otros conceptos se añaden al
enfoque para aumentar todavía más la capacidad de expresar ambigüedad y así,
multiplicar las ventajas.
Los objetos son definidos por su nombre, asociado con una dirección de la
memoria de la máquina. Esta definición puede considerar además las propiedades que,
generalmente, se clasifican en atributos y operaciones, también denominadas métodos.
objeto ≡ {nombre} ó {nombre, propiedades} ó {nombre, atributos, operaciones}
Atributo: propiedad de un objeto que expresa que está compuesto por un objeto
o una variable software tradicional. Por ejemplo, el atributo círculo1 expresa que
el objeto ventana está compuesto por el objeto círculo1. Y, radio expresa que
círculo1 contiene la variable software tradicional radio. Los denominados
lenguajes puros de programación orientados a objetos (Por ejemplo, SmallTalk)
sólo admiten atributos que sean objetos. Los llamados lenguajes híbridos (por
ejemplo, Java) admiten también como atributos variables software tradicionales.
37
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Operación: propiedad de un objeto que expresa su capacidad para ejecutar la
operación indicada por el nombre de la operación. Por ejemplo, Pintar del objeto
círculo1. Las operaciones representan rutinas, funciones, procedimientos, en fin,
código capaz de ejecutar acciones.
Los lenguajes de programación acostumbran a distinguir los atributos de las
operaciones para elevar la eficiencia de compilación, pero en principio, no hay razón
para distinguirlos. Los atributos y las operaciones expresan las propiedades de un
objeto, como se podría decir de un hornillo: es redondo, con diámetro de 15 cm. y
calienta.
El nombre del objeto o, en su lugar, la dirección de memoria del objeto es la
clave que distingue a un objeto de otro, aun cuando coincidan sus propiedades y valores
de esas propiedades. Dicho de otro modo, el nombre o la dirección de memoria del
objeto expresan la identidad del objeto.
2.2 La globalidad de los atributos de un objeto
En el enfoque de objetos, los atributos de un objeto son globales para todas las
operaciones de ese objeto. Es decir, cualquier línea de código de cualquier método de un
objeto tiene acceso inmediato a todos los atributos del objeto.
La globalidad de los atributos facilita el acceso directo a los atributos, en el
interior del objeto. Pero tiene dos inconvenientes:

Cuando una operación de un objeto quiere usar otra operación del mismo
objeto, la cabecera de la operación invocada se torna insuficiente para
conocer cómo usarla porque nada dice acerca de su relación con los atributos
del objeto. La operación que quiere usar a otra operación no sabe, mirando la
cabecera de esa otra operación, si comparten y actúan sobre los mismos
atributos. Por tanto, hay que revisar todo el código de la operación que se
quiere usar, antes de usarlo.

Cuando se modifica alguna línea de código de una operación de un objeto
hay que revisar todas las líneas de código de todas las operaciones de ese
objeto para determinar las consecuencias de la modificación porque,
38
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
potencialmente, todas las líneas de código del objeto están relacionadas a
través de los atributos. Una modificación, dentro de una operación, que actúe
sobre algún atributo del objeto puede afectar a cualquier otra operación del
objeto sin que esto se pueda detectar mirando las cabeceras de las
operaciones.
Resumiendo, siempre que un objeto posea atributos estos atributos entrelazan a
todas las operaciones del objeto, potencialmente. Por tanto, se dificulta cualquier
incursión al interior del objeto porque hay que revisar mucho código para descubrir las
relaciones encubiertas detrás de la globalidad. Como los objetos tienen atributos, por su
propia naturaleza, y las modificaciones son frecuentes, conviene diseñar objetos
pequeños, con pocas operaciones y con poco código en las operaciones. De lo contrario,
la complejidad del interior de los objetos provocará innumerables problemas. Un objeto
muy grande ofrece es más difícil de mantener que varios objetos pequeños.
2.3 Visibilidad de los atributos y operaciones
Un objeto, además de todo lo dicho, es una parcela de software con fronteras
bien definidas. En el interior, sus elementos pueden acceder unos a otros sin restricción
alguna. Los atributos de un objeto son globales para las operaciones de ese objeto.
Desde el exterior, sin embargo, el acceso a cada elemento (atributo u operación) está
regulado por un “control de visibilidad”. El término visibilidad se utiliza como
sinónimo de accesibilidad.
Los elementos designados como públicos son accesibles a todos los objetos del
sistema software. Los elementos designados como privados no son accesibles desde el
exterior. Es decir, son de uso exclusivo del objeto que los contiene. Hay también otras
categorías de visibilidad, pero ahora confunden más que aclaran.
A menudo, y a veces de forma automática, se asocian dos operaciones públicas
(dameX y asignaX) por cada atributo privado X para acceder al atributo desde otro
objeto. En inglés se les denomina “getX” y “setX”, respectivamente. Estas operaciones
deben ser utilizadas con cuidado puesto que son contradictorias con la intención de
declarar atributos privados o de uso exclusivo.
39
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
2.4 Representación gráfica
Para representar gráficamente los diseños software se han propuesto multitud de
esquemas, tanto para el estructurado como para los objetos. En el caso de los objetos ha
prevalecido el llamado “Unified Modeling Language” (UML) [Booch 99]. Actualmente
es un estándar reconocido y por tanto, útil para facilitar la comunicación entre los
desarrolladores de software.
El nombre de este estándar “Lenguaje unificado de modelado” suscita diversas
confusiones. Por esta causa conviene precisar que UML es un sistema de símbolos y
diagramas (lenguaje) para expresar (modelar) los diseños de los sistemas software, en el
mismo sentido que los planos de una máquina. La palabra unificado refleja el acuerdo
de sus autores.
Objeto
UML representa a los objetos mediante cajas. Si se utiliza la definición
extendida de objeto, la caja marca tres zonas: la superior contiene el nombre del objeto,
subrayado; la zona central contiene los atributos y la inferior, las operaciones o
métodos. Si se utiliza la definición compacta, la caja sólo contiene el nombre del objeto,
subrayado. Figura 2.1. En UML los elementos públicos van precedidos del signo “+” y
los elementos privados del signo “-“, aunque no se han incluido en la figura por
simplicidad.
Objeto
Objeto
atributos
operaciones()
Figura 2.1 Representación de un objeto en UML
Mensaje
UML representa un mensaje mediante una línea dirigida etiquetada con el
nombre de su operación. La línea se dirige del objeto que solicita la operación hacia el
40
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
objeto que realiza la operación. Por tanto, la etiqueta de la línea expresa una propiedad
del objeto que recibe la línea. Figura 2.2.
operación()
Figura 2.2 Representación de un mensaje en UML
Intercambio de mensajes
Para representar el intercambio de mensajes, durante el funcionamiento del
sistema, UML dispone de un tipo de esquema llamado diagrama de interacción. Cada
diagrama sólo refleja un fragmento importante del funcionamiento del sistema.
En UML existen dos variantes de diagramas de interacción: los diagramas de
secuencia y los diagramas de colaboración. Ambos son equivalentes, pero difieren en
los aspectos que resaltan. Los diagramas de secuencia destacan el orden temporal
(secuencia) de los mensajes, mientras que los diagramas de colaboración destacan la
organización de los objetos.
Diagrama de secuencias
Los diagramas de secuencias se han convertido en una de las representaciones
más populares de UML debido a su simplicidad y capacidad de expresión. Su éxito
radica en la sencillez y, aún más importante, que es muy fácil interpretarlos
correctamente. Por esta razón serán los diagramas que usaremos preferentemente en el
curso. Figura 2.3.
Los objetos que participan en la interacción se dibujan, horizontalmente, en la
parte superior del diagrama a través de sus esquemas simplificados (cajas conteniendo
sólo el nombre subrayado). Debajo de cada objeto se dibuja una línea vertical
discontinua llamada línea de vida que indica, en el eje tiempo, la existencia del objeto.
Los mensajes se colocan entre las líneas de vida de los objetos, siguiendo la
secuencia de ejecución. Si se quiere resaltar la devolución de algún valor, se puede
41
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
dibujar una flecha discontinua apuntando hacia el objeto emisor, etiquetada con el
nombre del valor de retorno.
Objeto1
Objeto3
<<create>>
Objeto2
operacionA()
operacionB()
operacionC()
valorRetorno
<<destroy>>
Figura 2.3 Diagrama de secuencias en UML
Para indicar la creación o destrucción de un objeto se utilizan, respectivamente,
las etiquetas estereotipadas <<create>> y <<destroy>> en el mensaje que se le envía al
objeto. La creación de un objeto se distingue dirigiendo el mensaje a la caja que
representa al objeto. La destrucción de un objeto se muestra dibujando una X grande al
final de su línea vida. En el siguiente capítulo se estudiará con detalle la creación de
objetos.
Los rectángulos que aparecen sobre las líneas de vida de los objetos se llaman
focos de control. El foco de control representa el período de tiempo durante el cual el
objeto está ejecutando una acción y tiene el control del sistema.
La Figura 2.4 muestra el diagrama de secuencias para crear y pintar los círculos
del ejemplo. El diagrama se concentra sólo en este aspecto del funcionamiento del
sistema y omite cualquier otro. Por ejemplo, se omite el intercambio de mensajes entre
cada objeto círculo y los objetos formularios. Si interesa describir de forma gráfica ese
intercambio se construye otro diagrama de secuencias para expresarlo.
42
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Ventana
<<create>>
Circulo1
<<create>>
Circulo2
Pintar()
Pintar()
Figura 2.4 Diagrama de secuencia para pintar dos círculos
Los mensajes de creación (<<create>>) de Ventana a Círculo1 y Círculo2 del
diagrama se corresponden con las líneas de código Java:
circulo1 = new Circulo();
circulo2 = new Circulo();
Y los mensajes Pintar() de Ventana a Círculo1 y Círculo2 del diagrama se
corresponden con las líneas de código Java:
circulo1.paint(g);
circulo2.paint(g);
La facilidad para apreciar las secuencias de mensajes e insertar nuevos pasos de
secuencia hace de este tipo de diagrama una herramienta muy útil para el diseño del
funcionamiento del sistema. Aunque UML admite representar más cosas en el diagrama
de secuencias, por ejemplo alternativas, es preferible mantenerlo sencillo y usar más de
un diagrama para conservar su facilidad de interpretación y modificación.
43
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Diagrama de colaboración
Un diagrama de colaboración es un diagrama de interacción que resalta la
organización de los objetos que envían y reciben los mensajes. Este tipo de diagrama
muestra un conjunto de objetos, los enlaces entre ellos y los mensajes que intercambian.
Se puede asociar un diagrama de colaboración con un grafo, donde los nodos del
grafo son los objetos y los arcos son los enlaces. Un enlace es una instancia de una
asociación o una dependencia entre clases. Se representa con una línea continua que une
los dos objetos. Figura 2.5.
Objeto1
1. <<create>>
2. operacionA()
3. <<destroy>>
Objeto2
Objeto3
2.1. operacionB()
2.2. operacionC()
Figura 2.5 Diagrama de colaboración en UML
Los mensajes se escriben junto a los enlaces, indicando el sentido con una flecha
que apunta hacia al objeto receptor y numerándolos para expresar el orden de ejecución.
Se pueden representar mensajes anidados utilizando la numeración decimal de Dewey
(1 es el primer mensaje, 1.1 es el primer mensaje dentro del mensaje 1, 1.2 es el
segundo mensaje dentro del mensaje 1,...).
Siguiendo la numeración, el primer y segundo mensaje los emite Objeto1 hacia
Objeto2, después Objetos2 emite dos mensajes hacia el Objeto3, y por último, el
Objeto1 manda un mensaje al Objeto2.
La Figura 2.6 muestra el diagrama de colaboración para crear y pintar los
círculos del ejemplo.
44
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
1.<<create>>
3.Pintar()
Ventana
Circulo1
2.<<create>>
4.Pintar()
Circulo2
Figura 2.6 Diagrama de colaboración para pintar dos círculos
El diagrama de colaboración tiene la ventaja de ofrecer una vista de conjunto de
la estructura y el funcionamiento, pero al realzar la estructura oscurece el
funcionamiento. Hay que seguir la secuencia de mensajes saltando de una línea a otra,
buscando la numeración, como se aprecia en la figura. Marea seguir la secuencia de
mensajes <<create>>, <<create>>, Pintar(), Pintar() que emite el objeto ventana.
Además, la forma de representar la secuencia dificulta insertar nuevos pasos en
la secuencia. Es decir, también se dificulta modificar el diseño. Por tanto, conviene usar
el diagrama de colaboración cuando no interese demasiado seguir el funcionamiento y
cuando se esperen pocas modificaciones del diseño.
45
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
2.5 Ejemplo de diseño. Control de acceso
A continuación se desarrolla el diseño del control de acceso a un cajero con el
objetivo de mostrar y estudiar criterios de diseño para conseguir plasticidad, es decir
facilidad de modificación.
La tarea
La tarea del control de acceso (tradicional) de un cajero automático consiste en
aceptar o rechazar el acceso de de una persona a los servicios del cajero, según coincida
o no la clave dada por la persona y la clave asociada con la tarjeta de cliente.
El diseño del sistema
Un diseño se puede comenzar desde perspectivas diferentes. Por ejemplo,
considerando la relación del sistema con su entorno. Figura 2.7.
sistema
lector de tarjetas
interfaz
cliente
interfaz
lector
de
tarjetas
cliente
control
de
acceso
Figura 2.7 Diseño considerando el entorno del sistema
El sistema software debe interactuar con un equipo lector de tarjetas y con un
cliente. Para facilitar que el entorno cambie sin afectar demasiado al interior del sistema
conviene debilitar la relación del interior con el exterior. Una manera de pensar este
diseño es imaginar que el software es blando y su entorno es duro, y colocar objetos que
sirvan de “tiritas” para evitar rozaduras. El objeto “tirita” con el equipo lector de tarjetas
pudiera tener el nombre interfaz lector de tarjetas. El objeto “tirita” con el cliente
pudiera denominarse interfaz cliente. La tarea de ambos objetos es servir de interlocutor
46
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
entre el sistema y los elementos del entorno. Son la fuente de información del exterior
del sistema software. La tarea de investigar la coincidencia de las claves y decidir el
acceso al cajero se le encarga a un objeto que se puede llamar control de acceso. Cada
objeto tiene asignada sólo una tarea, no hay “pluriempleo”.
Diseño del mecanismo de aceptación
El diseño del mecanismo de aceptación se muestra en la Figura 2.8. El resto del
funcionamiento del sistema, incluyendo cómo se obtiene la información, se considera
secundario para esta parte del diseño y se omite para evitar distracciones. El diagrama
resalta lo importante y excluye lo demás.
InterfazLectorTarjeta
ControlAcceso
InterfazCliente
{el siguiente
objeto}
trabajar()
obtenerClave()
clave
obtenerClave()()
clave
trabajar()
Figura 2.8 Diagrama de secuencia de una autorización de acceso
Cuando el equipo lector de tarjetas recibe una tarjeta de cliente, su software
interno le avisa, de alguna forma, al objeto interfaz lector de tarjetas. Éste a su vez, da
comienzo al trabajo del resto del sistema software, mandando un mensaje (trabajar) al
objeto control de acceso. Dicho de otro modo, el objeto interfaz lector de tarjetas
invoca la operación trabajar del objeto control de acceso.
La operación trabajar contiene el algoritmo de control de acceso y conoce a
quién debe pedirle la información que necesita el algoritmo. Le pide al objeto interfaz
lector de tarjetas el valor de la clave asociada con la tarjeta y también le pide al objeto
interfaz cliente el valor de la clave que debe dar el cliente. Si ambos valores coinciden
acepta el acceso y da paso al trabajo del siguiente objeto, excluido del dibujo.
47
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Criterios de diseño
En el diseño se han utilizado dos criterios combinados. Uno ha sido debilitar las
relaciones del interior hacia el exterior, colocando objetos en la frontera del sistema para
que sirvan de interlocutores. Si se producen cambios en el exterior, estos objetos deben
absorber los cambios para que no se propaguen al interior. Desempeñan una función
semejante a la de muelles o amortiguadores.
El segundo criterio de diseño ha procurado que cada tarea quede confinada en un
solo objeto y además, que cada objeto se ocupe sólo de una tarea:

El objeto interfaz lector de tarjetas se ocupa de mediar entre el equipo lector y el
sistema software. De cara al sistema software, que es lo relevante para el diseño,
este objeto desempeña dos funciones: servir de fuente de información a los
objetos del sistema y dar la orden para que empiece el trabajo. Ni siquiera se
ocupa de saber qué información necesita para trabajar el objeto al que le da la
orden de trabajar.

El objeto control de acceso se ocupa de permitir o rechazar el acceso a los
servicios del cajero automático. Sabe qué hacer y cómo hacerlo.

El objeto interfaz cliente se encarga de mediar entre el cliente y el sistema
software. De cara al sistema software, suministra el valor de la clave dada por el
cliente.
Objetivos y beneficios
Los objetivos del diseño han sido conseguir piezas “autosuficientes” débilmente
relacionadas entre sí y con el exterior para:
1. Facilitar el desarrollo progresivo de sistemas, mediante prototipos evolutivos. Es
decir, sistemas que comienzan siendo “de juguete”, pero con las funciones básicas,
y que “maduran” poco a poco por aproximaciones o ensayo y error. Por ejemplo,
el desarrollo del sistema de control de acceso comenzando por el mecanismo de
aceptación y, gradualmente, mejorar sus funciones añadiendo el mecanismo de
rechazo, y los mecanismos de adquisición de información. En los primeros
prototipos, los objetos interfaz pueden “inventar” la información y, una vez
resuelto el diseño de la aceptación y el rechazo, se puede abordar el diseño de los
48
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
mecanismos de adquisición. La prudencia sugiere que el orden de prioridad debe
estar dado por el orden de riesgo del proyecto, empezando por atender aquello que
suponga el mayor riesgo para el proyecto.
2. Facilitar el aumento de la velocidad de desarrollo mediante el desarrollo
simultáneo de mecanismos relacionados. Por ejemplo, el desarrollo al mismo
tiempo de los mecanismos de aceptación y de adquisición de información del
lector y del cliente.
3. Facilitar las modificaciones de los sistemas, disminuyendo la dificultad que ofrece
la globalidad de los atributos a las modificaciones, facilitando la localización de
las modificaciones y además, reduciendo su propagación.
Inconvenientes
Pero, como casi todo, los precedentes criterios de diseño también tienen
inconvenientes. Posiblemente, los más relevantes sean:
1. Puede aumentar la cantidad de mensajes, como sucede en el mecanismo de
aceptación, donde control de acceso solicita el valor de la clave a interfaz lector
de tarjetas. Los criterios tradicionales de diseño sugieren incluir el valor de la
clave en el mensaje trabajar que envía interfaz lector de tarjetas a control de
acceso. Es decir, trabajar(clave). De esta forma se aumenta la eficiencia de la
máquina, al reducir la cantidad de mensajes, y se aplica la idea de
“transparencia”: el elemento que invoca a otro debe conocerlo todo acerca del
invocado. Pero entonces, una parte de la tarea de control de acceso se traspasa a
interfaz lector de tarjetas, cuyo objetivo es ajeno a esta tarea. En el caso de
producirse cambios en la tarea de control de acceso habría que buscar en qué
objetos está disgregada y, posiblemente, modificarlos a todos.
2. Aumenta la cantidad de objetos porque especializa a los objetos en una sola
tarea. Por ejemplo, dedica un objeto a la tarea de interlocutor con el equipo
lector y otro objeto al control de acceso. Pero, si ambas tareas estuviesen en un
solo objeto sería difícil desarrollarlas en paralelo y modificar cualquiera de ellas.
3. Demanda otra forma de ver el diseño y otros criterios, que pueden ser arduos de
adquirir, si ya hay unos criterios arraigados.
49
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Diseño del mecanismo de rechazo
El sistema debe rechazar el acceso a los servicios del cajero cuando el valor de la
clave dada por la persona no coincide con el valor de la clave asociada a la tarjeta. En
este caso alguien (no el diseñador) debe precisar qué comportamiento debe tener del
sistema. Suponiendo una respuesta simple: se notifica a la persona la causa del rechazo
y se termina la sesión de trabajo. La Figura 2.9 muestra un diseño.
InterfazLectorTarjeta
ControlAcceso
InterfazRechazo
informarRechazo()
finalizarSesion()
Figura 2.9 Diagrama de secuencias del rechazo de un acceso
El objeto control de acceso solicita al objeto interfaz rechazo que informe a la
persona la causa del rechazo y le avisa al objeto interfaz lector de tarjetas que la sesión
ha finalizado. Lo que haga este último objeto es asunto de otro diseño. En los primeros
prototipos se puede limitar a publicar un texto en pantalla.
El mensaje para solicitar que se notifique a la persona se envía a un objeto
interfaz nuevo, concebido sólo con este fin. El objetivo es debilitar la relación entre los
mecanismos e incluso aislarlos, si procede. Aunque los mecanismos de aceptación y
rechazo están dentro del mismo objeto, el primero recibe la información del objeto
interfaz cliente y el segundo manda información al objeto interfaz rechazo. Ambos
mecanismos se pueden diseñar y probar sin demasiada interferencia entre ellos.
Además, los objetos interfaz cliente e interfaz rechazo son independientes entre sí, de
manera que admiten un diseño y ajuste por separado.
El diseño del mecanismo de rechazo se podría hacer en la figura que expresa el
diseño del mecanismo de aceptación, para ahorrar esquemas, pero la figura se complica
50
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
y además, se reduce la ventaja de tratar por separado ambos mecanismos. Si se está
trabajando en régimen de prototipos evolutivos conviene hacer primero el prototipo del
mecanismo de aceptación, probarlo, y después añadirle el mecanismo de rechazo. Se
aconseja ir despacio cuando hay prisa y no pensar en demasiadas cosas al mismo
tiempo.
Reflexiones sobre el diseño del sistema
1. Se han distribuido las tareas del mecanismo que se quiere obtener. A cada objeto
se le ha encargado de una tarea para que se ocupe completamente de ella.
Dividir una tarea o mecanismo provoca fuertes dependencias entre los elementos
que dificultan la velocidad de desarrollo y las modificaciones. La colaboración
entre los objetos produce el resultado deseado.
2. Cada pieza está especializada en una actividad concreta. No hay “pluriempleo”.
El desarrollo y las modificaciones también se dificultan si se agrupan varias
tareas en un elemento dada la globalidad en el interior de los objetos. La
naturaleza de la tarea de interfaz del dispositivo de lectura es independiente de la
naturaleza de la tarea de control de acceso, aunque estén relacionadas. Por tanto,
cualquiera de ellas puede cambiar y no hay que modificar a la otra, siempre que
no se afecte la relación. Pero, si están mezcladas en un solo objeto, entonces los
cambios en una pueden afectar a la otra, a causa de la globalidad que existe
dentro de un objeto.
3. Con la finalidad de potenciar todavía más, las facilidades de desarrollo y
mantenimiento, algunos objetos delegan parte de su tarea a otros objetos. Por
ejemplo, el objeto control de acceso delega en los objetos interfaz cliente e
interfaz rechazo las tareas de comunicación con la persona que usa el cajero. Se
separa la parte esencial de lo accesorio: el algoritmo de control de acceso de la
forma de comunicación con la persona. Como lo accesorio tiene más
probabilidad de cambio que lo esencial, esta separación evita tocar la esencia
cuando se modifique lo accesorio. La delegación es una técnica de diseño
fundamental en el software evolutivo porque mantiene las relaciones entre las
partes pero las debilita introduciendo ambigüedad. El objeto que delega depende
del objeto delegado, pero prácticamente sólo depende de la sintaxis del mensaje;
51
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
no le importa cómo el delegado realiza la parte encomendada y, a menudo, ni
siquiera le importa el resultado.
4. Para facilitar la evolución del sistema, ningún elemento software, por sí solo,
define la función del mecanismo. La función del sistema queda implícita en la
descripción de la interacción entre sus piezas, como sucede en el plano de una
máquina. Al no existir una definición explícita del mecanismo se puede añadir y
quitar elementos o tareas sin preocuparse por su efecto en la definición. Sin
embargo, puede ser conveniente lo contrario. Dedicar un objeto a la tarea de
controlar una tarea o mecanismo, como un director de orquesta, para facilitar las
modificaciones en la secuencia de ejecución.
2.6 Refactorización
Se denomina refactorización a los procesos que modifican el sistema para
mejorar alguna cualidad interna, sin alterar las funciones del sistema. La aparición y uso
frecuente de este término refleja un cambio profundo de forma de pensar el desarrollo
de software. La forma tradicional aspira alcanzar un diseño perfecto, muy bien pensado,
después de determinar completamente qué se quiere. Si hay que mejorar algo es porque
no se hizo bien.
La refactorización acepta que el objetivo del diseño es funcionar a tiempo, que
no es perfecto, ni se pretende que lo sea; que después de probado el diseño funcionando,
ya se podrá mejorar. Quizás en ese momento se le cambie el nombre a interfaz cliente
por interfaz clave para indicar su especialidad o se tome otra decisión.
Aceptar y utilizar la refactorización es aproximarse a las condiciones reales del
universo software y a la humildad humana.
52
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
2.7 Encapsulado y principio de ocultación, una confusión
frecuente
Como un objeto es una parcela de software, a menudo, se dice que un objeto
encapsula sus atributos y operaciones. Hasta ahí bien, porque una parcela con fronteras
precisas se puede imaginar como una cápsula o recipiente. El problema surge cuando se
asocian las ideas de encapsulado con ocultación de información, una técnica de diseño
que primero fue denigrada y luego alabada, pero confundida por casi todos los autores.
El principio de ocultación de información apareció como un nuevo modo de
dividir en módulos, en el amanecer de las ideas estructuradas, cuando se le cantaba a las
virtudes de la programación modular. El autor del principio, David L. Parnas, criticó la
forma usual de dividir en módulos y propuso otra forma radicalmente distinta para
conseguir, de verdad, las prometidas facilidades en el desarrollo y el mantenimiento del
software. La propuesta era tan distinta que, inicialmente, el trabajo [Parnas 72] fue
rechazado porque nadie lo hacía de ese modo y además, se convirtió en una fuente de
dificultades personales para su autor.
Durante mucho tiempo, el principio de ocultación de información fue denigrado
porque proponía una perspectiva del software opuesta a la perspectiva reinante. Pero las
ideas cambian y los objetos aprovecharon el principio de ocultación a su favor,
identificando encapsulado con principio de ocultación. Así, las virtudes de este
principio se convertían en una propiedad intrínseca (automática) de los objetos. Gracias
a que los objetos encapsulan y que encapsular equivale a usar el principio de ocultación
de información, los objetos facilitan el desarrollo y el mantenimiento del software.
Dicho de otra manera, usar objetos facilita por sí sólo las modificaciones. Pero esto es
una falsa inferencia porque uno de los antecedentes es falso: “encapsular equivale a usar
el principio de ocultación”.
Es cierto que el enfoque de objetos facilita algunas formas de desarrollo de
software, por ejemplo los prototipos evolutivos y el diseño en paralelo, y que también
facilita las modificaciones, pero esas facilidades no son intrínsecas, ni automáticas. Hay
que conseguirlas con un diseño que realce la autosuficiencia de los objetos y debilite las
relaciones entre ellos, aprovechando la capacidad de expresar ambigüedad del enfoque
53
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
de objetos. El encapsulado facilita, pero no otorga. Es una grave equivocación creer que
los objetos regalan las facilidades citadas.
La frontera de un objeto (cápsula) oculta la implementación de sus elementos de
un modo semejante a la forma que la frontera de una rutina oculta el código que
contiene. Como un objeto contiene, conceptualmente, más información que una rutina,
un objeto oculta más información que una rutina y esto es un punto a favor de los
objetos.
Además, la frontera de un objeto impide el acceso directo a sus elementos, desde
otro objeto. La referencia a cualquier elemento de otro objeto debe citar, explícitamente,
al objeto propietario del elemento (objeto.elemento). Esto amplía notablemente la
capacidad para expresar ambigüedad dado que el objeto es una variable y,
consecuentemente, es otro punto a favor de los objetos.
Y por último, el control de la visibilidad de los elementos también ayuda a
expresar ambigüedad porque impide el acceso a los elementos privados. Estos
elementos pueden cambiar e incluso dejar de existir y ningún objeto ajeno se afecta
porque no los utilizan (si no se ha hecho trampa).
Como se ha dicho, todas estas cualidades contribuyen a elevar la capacidad de
expresar ambigüedad de los objetos, son en definitiva potencialidades. Pero el principio
de ocultación es una forma concreta de obtener ambigüedad, concurran o no esas
potencialidades.
2.8 Un paso hacia el principio de ocultación de información
El principio de ocultación de información establece que:
1. Cada módulo estar caracterizado por su conocimiento de una decisión de diseño
que oculta de todos los otros módulos.
2. La interfaz o definición de cada módulo debe revelar lo menos posible del
trabajo interno del módulo.
Según el propio autor del principio, la formulación es simple, pero es difícil su
adquisición como habilidad de diseño. Por esta causa, el curso lo abordará de forma
54
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
progresiva. De momento vale discutir el siguiente ejemplo. Se trata de la operación de
autorizar o denegar la extracción de una cantidad de dinero en un cajero automático. La
Figura 2.10 muestra dos soluciones posibles:
1. El objeto :extracción le pide el saldo al objeto :cuenta para decidir.
2. El objeto :extracción* le informa la cantidad al objeto :cuenta* y le pide que
decida por él mismo.
:cuenta
:extracción
:cuenta*
:extracción*
damesaldo
autorizar(cantidad)
(1)
(2)
Figura 2.10 Dos soluciones para una misma tarea
Concentrar la tarea
La primera solución disgrega el mecanismo de autorización en dos objetos,
ligando fuertemente al objeto extracción con el objeto cuenta. Se puede decir que la
relación de extracción a cuenta es unívoca, en el sentido de que cualquier cambio en el
mecanismo de autorización de la cuenta afecta a extracción. Por ejemplo, si se añade
otra condición de autorización a cuenta hay que modificar a extracción para que
considere esa nueva condición.
La separación del mecanismo de autorización, en dos objetos, impide que
cualquiera de ellos esté caracterizado por una decisión de diseño porque comparten ese
mecanismo. La misma causa impide que el objeto cuenta revele lo menos posible su
trabajo interno porque está obligado a dar el valor de su saldo y de cualquier otro factor
(atributo) que influya en la autorización. Ni siquiera la declaración de saldo como
atributo privado impide que salga de cuenta porque el diseño (la separación del
55
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
mecanismo) obliga la exportación de saldo a través de la operación pública damesaldo.
Por tanto, la primera solución no cumple ninguna de las condiciones que exige el
principio de ocultación, aunque el atributo saldo sea privado, porque disgrega el
mecanismo de autorización en dos objetos.
Al contrario, la concentración del mecanismo de autorización en un solo objeto
facilita que la segunda solución satisfaga las dos condiciones del principio de
ocultación. El objeto extracción* se caracteriza por ocuparse de la secuencia de
extracción, mientras que el objeto cuenta* se ocupa de todo lo relacionado con la
cuenta. La interfaz del objeto cuenta* es mínima, independientemente de la cantidad de
factores que influyan en la autorización. El atributo saldo sólo le importa al objeto
cuenta*, ningún otro objeto lo necesita para calcular o decidir, da igual que sea o no
privado.
La segunda solución mantiene la dependencia de la extracción con la cuenta,
porque ambos conceptos están indisolublemente ligados, pero debilita la relación del
objeto extracción* hacia el objeto cuenta*. El objeto cuenta* puede ser sustituido por
otro sin afectar al objeto extracción*. De este modo, se consigue la facilidad de
modificación y de desarrollo en paralelo. Tanto, extracción*, como cuenta* pueden ser
desarrollados en paralelo y modificados, sin afectarse demasiado el uno al otro.
De nuevo, otra forma de pensar
El primer diseño es un reflejo directo de la forma usual de pensar el software,
pero entorpece el desarrollo de prototipos evolutivos, obstaculiza el desarrollo por
separado de las partes del sistema y dificulta las modificaciones porque aumenta la
cantidad de partes donde hay que localizar y hacer las modificaciones. El segundo
diseño distorsiona la forma usual de pensar el software, pero facilita todas esas
actividades, en virtud de la relación de ambigüedad (indiferencia) de extracción* hacia
cuenta*.
Como la separación del mecanismo responde a una forma usual de pensar el
software, en datos y funciones, también es usual que sea necesario quebrantar la
privacidad de los atributos mediante operaciones públicas, de manera que la declaración
de privacidad resulta ser un autoengaño usual. Por tanto, en vez de declarar privados a
56
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
los atributos, conviene pensar el diseño de forma tal que no sea necesario declararlos
privados, aunque se haga por razones de seguridad.
El cambio de modo de pensar el software ha sido y es uno de los mayores
problemas para aplicar el principio de ocultación de información. Aunque el origen y el
objetivo de los objetos (simulación) son ajenos al principio de ocultación de
información, la aplicación de este principio conduce a diseños software próximos a los
diseños del enfoque de objetos.
2.9 La incertidumbre como solución
Incertidumbre es una palabra de amplio contenido semántico: problemático,
cuestionable, vago, no definido o determinado, dudoso, no seguro, ambiguo, sujeto a
oportunidad o cambio, no estable, variable, no confiable. Todos estos significados se
pueden agrupar en dos categorías: vaguedad (imprecisión) y ambigüedad. En general,

vaguedad se asocia con la dificultad de hacer distinciones agudas o precisas en
el mundo; esto es, algún dominio de interés es vago si no puede ser delimitado
por fronteras precisas. La vaguedad está asociada a un concepto que no está
definido del todo, ni ahora ni después.

ambigüedad se asocia con relaciones de uno a muchos; esto es, con situaciones
donde la elección entre dos o más alternativas se deja sin especificar. La
ambigüedad está asociada al desconocimiento de cuál es el concepto, de varios
conceptos posibles, definidos y precisos.
Cada uno de esas dos formas de incertidumbre (vaguedad y ambigüedad) se
relaciona con un conjunto de ideas emparentadas. Por ejemplo, con vaguedad se
relaciona borroso, nublado, sin claridad, indistinguible, brumoso, confuso, obtuso,
impreciso. Con ambigüedad, se relaciona variedad, no específico, relación uno a
muchos, generalidad, diversidad, divergencia.
La incertidumbre en el software se asocia con lo que falta por decir y se
manifiesta en infinitud de situaciones asociadas con los requisitos, la tecnología, las
personas involucradas (clientes, usuarios, desarrolladores,…), en fin, con todo. Pero se
57
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
olvida que la incertidumbre está asociada, sobre todo, con la creación. Y el desarrollo de
software es un acto de creación.
La incertidumbre ha sido considerada enemiga del desarrollo de software, al
punto de exigir su extinción antes de comenzar a desarrollar. Sin embargo desde
siempre, la incertidumbre es un recurso que los humanos introducen en la solución para
resolver problemas difíciles.
El oráculo de Delfos respondía con textos ambiguos a las preguntas que se le
formulaban. Los adivinos actuales repiten las mismas fórmulas de antaño. En algunos
transportes públicos se puede leer “la multa será de veinte veces el precio del billete”,
que simplifica el problema de renovar el cartel para que no se devalúe la multa. El juego
de ordenar ocho números colocados en nueve casillas no sería posible sin el margen de
la novena casilla vacía que permite el movimiento. El cálculo numérico de raíces
irracionales se realiza gracias a procesos cíclicos que toleran imprecisión en la
soluciones. Pero en general, estas soluciones, no son gratis; aumentan la complejidad de
la solución. Retomando el ejemplo del transporte público, hay que estar dispuesto a
pagar ahora un cartel más caro y más difícil de entender, para mañana ahorrarse la
renovación del cartel.
Las abstracciones son soluciones de ambigüedad. Una abstracción simplifica
porque muestra lo que se considera esencial y oculta todo lo demás. Quien observa o
maneja la abstracción no sabe, ni le interesa, qué oculta la abstracción. Ésta es la razón
de ser de las rutinas, no la de evitar repetir el código.
La incertidumbre en la solución, como solución, siempre ha estado ahí, pero
tapada por el paradigma filosófico vigente. La tapaba o la agredía porque contradice sus
propósitos: alcanzar el conocimiento absoluto, el control detallado de todo. La
incertidumbre se ha considerado accidente y no esencia. Se podía arrinconar y eliminar,
más tarde o temprano.
58
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
soluciones software basadas en la admisión de incertidumbre
modelos
variables
alternativas
rutinas
entidad-relación
objetos
agentes
diseño
métodos
desarrollo evolutivo
máquinas abstractas
desarrollo espiral
principio de ocultación
desarrollo caos
tipos abstractos
métodos ágiles
principio de sustitución
principio de abierto y cerrado
principio de inversión de dependencias
patrones de diseño
Figura 2.11. Soluciones software basadas en la admisión de incertidumbre
La Figura 2.11 refleja diversos recursos software cuya esencia es admitir
incertidumbre, tanto en el caso de los modelos, como en el diseño, como en los métodos
de desarrollo. En los modelos y diseño, la incertidumbre se manifiesta en forma de
ambigüedad, mientras que en los métodos lo hace en forma de vaguedad.
2.10 La ambigüedad es la clave
La ambigüedad es la clave de la versatilidad del software. Gracias a su
capacidad de ambigüedad, el software tiene capacidad para abordar muchas tareas y
además, para realizar una tarea en infinidad de situaciones distintas, en infinidad de
alternativas. La ambigüedad del software emana, básicamente, de las variables y de las
instrucciones que expresan alternativas, aunque también posee otras cualidades que
aumentan su capacidad de ambigüedad, según se aprecia en la Figura 2.11.
A continuación se estudiarán dos efectos de que se producen al introducir
ambigüedad en el diseño.
Influencia favorable sobre facilidad de desarrollo y modificación
Modularidad, cohesión, acoplamiento y, más recientemente privacidad, son
palabras que se emplean con frecuencia en el universo software como guías para el buen
diseño. Pero, si buen diseño significa conseguir facilidad de desarrollo y de
modificación, entonces esas palabras ayudan poco, casi nada.
59
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
El estudio del ejemplo del mecanismo de autorización ha demostrado que es
mejor diseñar con vistas a prescindir de la privacidad, que usar la privacidad y después
quebrantarla. El mismo estudio también demuestra que modularidad, cohesión y
acoplamiento dicen poco sobre las facilidades del diseño para ser modificado o
desarrollado en paralelo. Ambos diseños muestran el mismo grado de modularidad,
cohesión y acoplamiento, y sin embargo, son radicalmente distintos respecto a estas
facilidades e incluso respecto a la comprensión; tienen distintos significados.
El problema de la utilidad de cohesión y acoplamiento se debe a su polisemia;
hay muchas acepciones o interpretaciones de las dos palabras. El problema de la
modularidad es que se asocia la separación con la independencia. Estar separados no
significa ser independientes.
La separación de extracción de cuenta no consigue, por sí sola, que se pueda
cambiar cuenta sin afectar a extracción. Ni siquiera es posible independizar extracción
de cuenta porque están ligadas por el algoritmo. Por tanto, hablar de separar o
independizar es un camino equivocado o confuso en el mejor de los casos.
La clave para conseguir un sistema software con facilidades de desarrollo en
paralelo y de modificación consiste en introducir ambigüedad en el diseño. Hay diversas
maneras de hacerlo, por ejemplo utilizando elementos que desempeñen el papel de
abstracciones o debilitando las relaciones entre los elementos sustituyendo relaciones
unívocas por relaciones ambiguas, como se hizo en el caso del diseño del mecanismo de
autorización.
La Figura 2.12 ilustra una relación ambigua y una relación unívoca de un
elemento software hacia otro.
60
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
A
B
B’
Relación ambigua (indiferente) de A hacia B
A
B
A’
B’
Relación unívoca de A hacia B
Figura 2.12 Relaciones dirigidas de un elemento hacia otro
En el presente curso se denomina:
Relación ambigua aquella relación que se conserva y conserva sin cambios al
elemento dependiente cuando cambia el elemento independiente. Una relación ambigua
es indiferente a los cambios del elemento independiente. Por ejemplo, la relación entre
extracción* y cuenta* donde la dependencia se reduce a autoriza(cantidad). A
extracción* le son indiferentes los cambios en cuenta* respecto a la autorización.
Relación unívoca aquella relación dirigida que cambia y obliga a cambiar el
elemento dependiente cuando cambia el elemento independiente. Una relación unívoca
es sensible a los cambios, propaga los cambios de un elemento a otro. Por ejemplo, la
relación entre extracción y cuenta donde extracción depende de los datos de cuenta para
tomar decisiones. Cada vez que cuenta cambie para añadir algún dato, que influye sobre
la autorización, debe cambiar extracción para considerar ese nuevo dato.
La aplicación del principio de ocultación de información conduce a establecer
relaciones ambiguas. Los criterios de conseguir objetos autosuficientes y de colocar
objetos intermediarios entre el interior y el exterior del sistema conducen también a
establecer relaciones ambiguas. Por el contrario, los criterios de diseño estructurado
conducen necesariamente a relaciones unívocas dada la disociación de los elementos en
funciones y datos.
61
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
El fuerte enlace presente en las relaciones unívocas entorpece el desarrollo
simultáneo de los elementos, la modificación del sistema porque hay que buscar las
modificaciones
y
los
efectos
de
las
modificaciones
en
más
elementos.
Consecuentemente, las relaciones unívocas dificultan también el desarrollo de
prototipos evolutivos.
Las ideas de modularidad, cohesión, acoplamiento y privacidad ayudan poco,
como se dijo al principio, para conseguir facilidad de desarrollo simultáneo de
elementos, facilidad de modificación del sistema y otras cualidades asociadas con la
plasticidad del diseño. La ambigüedad ha demostrado ser una herramienta adecuada en
esta dirección
Influencia sobre el significado del diseño
La ambigüedad tiene la consecuencia práctica y visible de permitir el cambiar un
elemento por otro sin afectar a sus usuarios de elemento original, pero también tiene una
consecuencia semántica y velada. Cambia el significado del diseño. Para transformar
una relación unívoca en una relación ambigua hay que transformar también a los
elementos que participan en la relación.
Los elementos en una relación unívoca desempeñan una función distinta que en
una relación ambigua. En fin, son elementos distintos, aunque posean los mismos
nombres.
La Tabla 2.1 resume las tareas (función) de cada objeto software en los diseños
discutidos.
Diseño 1
Diseño 2
:extracción
Dirige
extracción
y
la
además,
secuencia
realiza
de :extracción* Dirige la secuencia de
la extracción.
autorización.
:cuenta Suministra los datos de la cuenta.
:cuenta* Realiza las tareas que dependen
de la cuenta.
Tabla 2.1 Tareas de los objetos en cada diseño
Los objetos de la izquierda (sin asterisco) se pueden clasificar dentro del
enfoque estructurado.
62
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
El objeto :extracción desempeña el papel de una función de transformación de
datos: recibe los datos cantidad y saldo, y los transforma en el dato saldo’, después de
la extracción. El objeto :cuenta desempeña el papel de un almacén de datos. Figura
2.13.
A pesar de desempeñar estos papeles estructurados, ambos elementos admiten la
clasificación de objetos, dada la ambigüedad del significado de objeto (cosa).
Diseño de Objetos Estructurado
InterfazExtraccion
Extraccion
Cuenta
Cuenta
Objeto datos
dameCantidad
cantidad
Extracción
dameSaldo()
saldo
asignarSaldo(saldo)
Objeto función
Figura 2.13 Diseño estructurado con ropaje de objetos
Los objetos (con asterisco) de la derecha de la Tabla 2.1 no admiten ninguna
clasificación dentro del enfoque estructurado. Ningún objeto es una función de
transformación de datos. El objeto :extracción* recibe y emite cantidad, sin que sufra
transformación alguna. El objeto :cuenta* recibe saldo y no emite nada; es un sumidero.
Ningún objeto, tampoco, es un almacén de datos porque tienen código. Figura 2.14.
63
Curso de OO dirigido por
la introducción de ambigüedad
Los pilares: objetos, mensajes y ambigüedad
Diseño Orientado a Objetos
cantidad
InterfazExtraccion
Extraccion
cantidad
No es una función de transformación
de datos , ni un almacén;
Extracción
Cuenta
es una COSA
obtenerCantidad()
autoriza(cantidad)
cantidad
Cuenta
No es un almacén de datos, ni una
función de transformación ;
es una COSA
Figura 2.14 Diseño orientado a objetos
Los diseños de :extracción* y :cuenta* son horripilantes desde la perspectiva del
pensamiento estructurado y tendrían que ser penalizados, como fue penalizado el
principio de ocultación de información por sus contemporáneos y después, confundido.
La causa fue el arraigo estructurado, el mismo que ha entorpecido y entorpece el
despliegue del enfoque de objetos.
Los objetos :extracción* y :cuenta* tienen su lugar natural dentro del enfoque
de objetos, donde se clasifican como cosas.
Los enfoques estructurado y de objetos tienen virtudes e inconvenientes.
Ninguno es mejor, ni peor que el otro, en sentido absoluto. Cada uno de ellos se debe
utilizar en las condiciones donde son mejores. El estructurado cuando la incertidumbre
alrededor del problema sea pequeña. Los objetos, cuando la incertidumbre sea
significativa y además, cuando se quiera libertad de diseño.
La mezcla de ambos enfoques puede ofrecer beneficios, pero en general, reduce
las virtudes y amplía los inconvenientes de los dos enfoques.
Bibliografía
[Parnas 72] David L. Parnas, “On the Criteria To Be Used in decomposing System
into Modules” Com. ACM, Dec 1972, Vol. 15, Nº 12, pp. 1053 – 1058.
[Booch 99] Grady Booch et al. “El lenguaje unificado de modelado” Ed.
Addison-Wesley, 1999
64