VI: MODULARIDAD

La modularidad es la capacidad que tiene un sistema de ser estudiado, visto o entendido como la unión de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común, realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo. Cada una de esas partes en que se encuentre dividido el sistema recibe el nombre de módulo. Idealmente un módulo debe poder cumplir las condiciones de caja negra, es decir, ser independiente del resto de los módulos y comunicarse con ellos (con todos o sólo con una parte) a través de unas entradas y salidas bien definidas.
Modularidad en Ciencias de la computación es la característica por la cual un programa de computador está compuesto de porciones que se conocen como módulos. El diseño estructurado es la técnica de diseño de algoritmos en que se basa la programación modular, paradigma de programación que persigue desarrollar programas modulares.


Modularidad y orientación a objetos. Traducción a Java de
diseños modulares
En esta asignatura sólo aplicaremos la orientación a objetos a fin de aprovechar mejor los mecanismos que el lenguaje Java ofrece para codificar nuestros diseños modulares. Sin embargo, este
estilo de programación conlleva un modo particular de abordar la estructuración de programas.
Veamos en primer lugar algunos aspectos conceptuales del mismo para pasar, seguidamente, a
aplicarlos en nuestro contexto.

Considerado como unidad de estructuración de programas, el concepto de clase equivale esencialmente al de módulo. Por tanto, sus fases de diseño son las mismas, si bien la forma de
especificar, utilizar e implementar difiere ligeramente entre un estilo y el otro. Las clases y los
objetos representan una manera alternativa de modelizar los datos (la información) de un programa.
En el estilo modular clásico, un módulo de datos define un tipo con un dominio de valores y
un conjunto de operaciones que trabajan con diversos parámetros, de los que al menos uno es del
propio tipo. En programación orientada a objetos, una clase de datos define una estructura de
atributos y operaciones que se particulariza (también se suele decir que se “instancia”) en cada
objeto de la misma que se crea. En este aspecto, una clase también hace el papel de “tipo” de
dichos objetos.
En el diseño modular clásico, una variable posee un valor del tipo al que pertenece y sobre
ella se aplican las operaciones de dicho tipo. Podemos decir que una variable contiene la información. Sin embargo, cada vez que se crea un objeto de una clase de datos, éste se convierte
en un representante de la estructura definida en tal clase, de forma que recibe como componentes sus atributos y sus operaciones (también llamadas métodos). En este caso el objeto es la
información.
La mayoría de lenguajes orientados a objetos introducen maneras de trabajar que pueden resultar sorprendentes si previamente se ha estudiado diseño modular, pero que son perfectamente
consistentes con la mencionada diferencia conceptual entre ambos estilos.
Por ejemplo, las operaciones de una clase se conciben para ser aplicadas sobre un objeto
concreto de la clase, y por eso se parametrizan de una manera especial, de tal manera que el
objeto que es creado, modificado o consultado por una operación no aparece explícitamente
en la lista de paramétros de la misma. Se mencionará sólo en las llamadas a dicha operación,
mientras que en el código de la misma es referido de forma implícita.
Otra práctica habitual es que las clases no se tratan igual que los tipos simples a la hora de
parametrizar las operaciones o respecto a la operación de asignación. La primera situación se
estudia en detalle en la primera sesión de laboratorio de la asignatura. En cuanto a la segunda,
cuando se desea producir dos objetos distintos con la misma información, no se habla de asignar
un objeto a otro sino de copiar (o también, clonar) un objeto en otro. De hecho, en la mayoría
de lenguajes orientados a objetos se permite realizar asignaciones entre objetos, pero con una
1semántica muy distinta a la de la asignación clásica. Al realizarse tal asignación entre objetos,
el resultado es que la misma información pasa a tener dos nombres (situación habitualmente
denominada “aliasing”), lo que puede dar lugar a efectos laterales difícilmente controlables.
Por ello, en nuestro contexto limitaremos estas asignaciones a un reducido número de casos
particulares que describiremos en su momento, aunque en otros contextos puede resultar útil
explotar esta compartición de información.
En la práctica, esta filosofía de trabajo da lugar a una serie de aspectos metodológicos nuevos
que presentamos en los apartados siguientes, aplicados de forma particular al lenguaje Java.