6.9 Future work
6.9.2 Determination of the effect of TG003 on normal tissues
El proyecto que usaremos para discutir sobre la interacción de objetos modela un visor para un reloj digital. El visor muestra las horas y los minutos separados por dos puntos (Figura 3.1). Para este ejercicio, construiremos primeramente un reloj con un visor de 24 horas, de estilo europeo, por lo que muestra la hora desde las 00:00 (medianoche) hasta las 23:59 (un minuto antes de medianoche). Debido a que es un poco más difícil de construir un reloj de 12 horas, dejaremos este modelo para el final de este capítulo.
CAPÍTULO
Interacción de objetos
3
Principales conceptos que se abordan en este
capítulo:
abstracción creación de objetos llamadas a métodos
modularización diagramas de objetos depuradores
Construcciones Java que se abordan en este capítulo
clases como tipos, operadores lógicos (&&, ||), concatenación de cadenas, operador módulo (%), construcción de objetos (new),llamadas a métodos (notación de punto), palabra clave this
11:03
Figura 3.1
El visor de un reloj digital
3.2
Abstracción y modularización
Una primera idea podría ser implementar totalmente el visor del reloj en una sola clase.
Después de todo, esto es lo que hemos visto hasta ahora: cómo construir clases para hacer un trabajo.
Sin embargo, abordaremos este problema de una manera un poco diferente. Veremos si podemos identificar en el problema, componentes que se puedan convertir en clases independientes; la razón de proceder así radica en la complejidad del problema. A medida que avancemos en este libro, los ejemplos que usamos y los programas que construimos se volverán más y más complejos. Tareas triviales tales como la de la máquina de boletos pueden ser resueltas como si fueran un único problema: se puede ver la tarea completa y divisar una solución usando una sola clase. En los problemas más complejos, esta es una visión demasiado simplista. Cuando un problema se agranda, se vuelve más difícil mantener todos los detalles al mismo tiempo.
La solución que usamos para tratar el problema de la complejidad es la abstracción:
dividimos el problema en subproblemas, luego en sub-subproblemas y así sucesiva- mente, hasta que los problemas resultan suficientemente fáciles de tratar. Una vez que resolvemos uno de los subproblemas no pensamos más sobre los detalles de esa parte, pero tratamos la solución hallada como un bloque de construcción para nuestro siguiente problema. Esta técnica se conoce como la técnica del divide y reinarás.
Veamos todo lo dicho con un ejemplo. Imaginemos a los ingenieros de una fábrica de coches diseñando un nuevo coche. Pueden pensar en partes del coche tales como: su forma exterior, el tamaño y ubicación del motor, el número y el tamaño de los asientos en la zona de los pasajeros, la cantidad exacta de espacio entre las ruedas, etc. Por otro lado, otro ingeniero (en realidad, este es un equipo de ingenieros pero lo simpli- ficamos un poco en función del ejemplo), cuyo trabajo es diseñar el motor, piensa en las partes que componen un motor: los cilindros, el mecanismo de inyección, el car- burador, la electrónica, etc. Piensa en el motor no como una única entidad sino como un trabajo compuesto por varias partes, una de esas partes podría ser una bujía. Por lo tanto, hay un ingeniero (quizás en una fábrica diferente) que diseña las bujías. Piensa en las bujías como un artefacto compuesto por varias partes. Puede haber hecho estudios complejos para determinar exactamente la clase de metal que debe usar en los contactos o el tipo de material y el proceso de producción a emplear para su aislamiento. El mismo razonamiento es válido para muchas otras partes del coche. Un diseñador del nivel más alto pensará una rueda como una única parte; otro ingeniero ubicado mucho más abajo en la cadena de diseño pasará sus días pensando sobre la composición química para producir el mejor material para construir los neumáticos. Para el ingeniero de los neumáticos, el neumático es algo complejo. La fábrica de coches comprará los neumá- ticos a una fábrica por lo que los verá como una única entidad y esto es la abstracción. Por ejemplo, el ingeniero de la fábrica de coches hace abstracciónde los detalles de
la fabricación de los neumáticos para concentrarse en los detalles de la construcción de una rueda. El diseñador que se ocupa de la forma del coche se abstrae de los deta- lles técnicos de las ruedas y del motor para concentrarse en el diseño del cuerpo del coche (se interesará por el tamaño del motor y de las ruedas).
El mismo argumento es cierto para cualquier otro componente. Mientras que algunas personas se ocupan de diseñar el espacio interior del coche, otros trabajan en desa- rrollar el tejido que usarán para cubrir los asientos.
58 Capítulo 3 Interacción de objetos
Concepto
La abstracciónes la
habilidad de ignorar los detalles de las partes para centrar la atención en un nivel más alto de un problema.
El punto es: si miramos detalladamente un coche, está compuesto de tantas partes que es imposible que una sola persona conozca todos los detalles de todas las partes al mismo tiempo. Si esto fuera necesario, jamás se hubiera construido un coche. La razón de que los coches se construyen exitosamente es que los ingenieros usan modu- larización y abstracción: dividen el coche en módulos independientes (rueda, motor, asiento, caja de cambios, etc.) y asignan grupos de gente para trabajar en cada módulo por separado. Cuando construyen un módulo usan abstracción: ven a ese módulo como un componente único que se utiliza para construir componentes más complejos. La modularización y la abstracción se complementan mutuamente. La modularización es el proceso de dividir cosas grandes (problemas) en partes más pequeñas, mientras que la abstracción es la habilidad de ignorar los detalles para concentrarse en el cuadro más grande.
3.3
Abstracción en software
Los mismos principios de modularización y de abstracción discutidos en la sección ante- rior se aplican en el desarrollo de software. En el caso de programas complejos, para mantener una visión global del problema tratamos de identificar los componentes que podemos programar como entidades independientes, y luego intentamos utilizar esos componentes como si fueran partes simples sin tener en cuenta su complejidad interna. En programación orientada a objetos, estos componentes y subcomponentes son objetos. Si estuviéramos tratando de construir un programa que modele un coche mediante un lenguaje orientado a objetos, intentaríamos hacer lo mismo que hacen los ingenieros: en lugar de implementar el coche en un único objeto monolítico, primeramente podrí- amos construir objetos independientes para un motor, una caja de cambios, una rueda, un asiento, etc., y luego ensamblar el objeto coche a partir de esos objetos más pequeños. No siempre resulta fácil identificar qué clases de objetos debe tener un sistema de soft- ware que resuelve determinado problema. Más adelante en este libro, tendremos mucho más para decir sobre este tema, pero por el momento, comenzaremos con un ejemplo relativamente simple. Y ahora volvamos a nuestro reloj digital.
3.4
Modularización en el ejemplo reloj
Demos una mirada más de cerca al ejemplo visor-del-reloj. Usando los conceptos de
abstracción de los que hemos hablado, simplemente queremos intentar encontrar la mejor manera de ver este ejemplo, para que podamos escribir algunas clases para imple- mentarlo. Una forma de verlo, es considerarlo como compuesto por un único visor con cuatro dígitos (dos dígitos para la hora y dos para los minutos). Si nos abstraemos nue- vamente de ese nivel tan bajo, podemos ver que también se podría considerar el visor como compuesto por dos visores de dos dígitos: un visor de dos dígitos para las horas y otro visor de dos dígitos para los minutos. Un par de dígitos comienza en cero, aumenta en uno cada hora y vuelve a ponerse en cero después de alcanzar su límite 23. El otro par de dígitos se vuelve a poner en cero después de alcanzar su límite 59. La similitud del comportamiento de estos dos visores podría llevarnos a abstraer nue- vamente y ver más allá del visor de las horas y del visor de los minutos de manera independiente. Podríamos, en cambio, pensar en ellos como objetos que pueden mos- trar valores desde cero hasta un determinado límite. El valor puede ser incrementado,
3.4 Modularización en el ejemplo reloj 59
Concepto
La modularización es el proceso de dividir un todo en partes bien definidas que pueden ser construidas y examinadas separadamente, las que interactúan de maneras bien definidas. 03 CAPITULO 03 8/1/07 17:37 Página 59
pero si alcanza el límite vuelve al valor cero. Parece que hemos encontrado un nivel de abstracción adecuado que nos permite representar la situación mediante una sola clase: la clase del visor de dos dígitos.
Para nuestro visor del reloj programaremos primero una clase para representar un visor de un número de dos dígitos (Figura 3.2); le pondremos un método de acceso para tomar su valor y dos métodos modificadores: uno para establecer el valor del límite y otro para incrementarlo. Una vez que tengamos definida esta clase, podremos crear dos objetos de esta clase con diferentes límites para construir el visor del reloj completo. 60 Capítulo 3 Interacción de objetos
03
Figura 3.2
El visor de un número de dos dígitos
3.5
Implementación del visor del reloj
Tal como lo mencionamos anteriormente, en vías de construir el visor del reloj cons- truiremos primero un visor que muestra un número de dos dígitos. Este visor necesita almacenar dos valores: uno es el límite hasta el que puede incrementarse el valor antes de volver a cero y el otro es el valor actual. Representaremos ambos en nuestra clase mediante campos enteros (Código 3.1).
public class VisorDeNumeros
{
private int limite; private int valor;
Se omitieron los constructores y los métodos. }
Código 3.1
Clase para el visor de un número de dos dígitos
public class VisorDeReloj
{
private VisorDeNumeros horas; private VisorDeNumeros minutos;
Se omitieron los constructores y los métodos. } Código 3.2 La clase VisorDeReloj contiene dos VisorDeNumeros
Más adelante, veremos los restantes detalles de esta clase. Primero, asumimos que podemos construir la clase VisorDeNumerosy pensar un poco más sobre el visor del reloj com- pleto como un objeto que internamente está compuesto por dos visores de números (uno para las horas y otro para los minutos). Cada uno de estos visores de números puede ser un campo en el visor del reloj (Código 3.2). Hacemos uso aquí de un detalle que no hemos mencionado antes: las clases definen tipos.
Concepto
Las clases definen tipos.El nombre de una clase puede ser usado como el tipo de una variable. Las variables cuyo tipo es una clase pueden almacenar objetos de dicha clase.
Cuando hablamos sobre los campos en el Capítulo 2, dijimos que la palabra «pri- vate» en la declaración del campo va seguida de un tipo y de un nombre para dicho campo. En este caso en particular, usamos la clase VisorDeNumeroscomo el tipo de
los campos de nombre horasy minutos, lo que muestra que los nombres de clase
pueden usarse como tipos.
El tipo de un campo especifica la naturaleza del valor que puede almacenarse en dicho campo. Si el tipo es una clase, el campo puede contener objetos de esa clase.