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