Hola, como continuación de lo anterior voy a insistir en algo que ya he
tratado de pasada pero que observo que sigue habiendo confusión y
dificultad en comprender, que es el manejo de los multiobjetos y en algunos
casos de los catálogos, el concepto de catálogo. Incluso en el ámbito
conceptual, es decir, cuando concebimos el funcionamiento que queremos
conseguir en el modelo de dominio y lo representamos en el modelo de
dominio, se requiere o vemos la necesidad de manejar determinadas
agrupaciones de objetos que recogen determinada información. En concreto,
en el ejemplo del libro, por ejemplo los precios de los productos o los
artículos que hay en venta. Evidentemente, en una operación de venta
tendremos un conjunto de artículos o de elementos de información, esto es
la descripción de cada uno de los artículos que se están vendiendo, en
este caso pues está representando la característica principal, sería la
de el precio que tiene el artículo y bueno como queremos manejar un grupo
más o menos numeroso de elementos con esa información, todos con esa
misma estructura o características o caracterización, pues llegamos a un
concepto de una colección o agrupación de esos objetos. Esto en un
diagrama estático como puede ser el modelo de dominio o en el diagrama de
clases de diseño, a este objeto en un caso o a esta clase en el otro caso
se representa así y su multiplicidad es decir la indicación de que son un
número determinado de ellos es mediante la cardinalidad. En esos diagramas
esto se representa así y no es más que eso, una colección de elementos
todos de la misma estructura o con la misma organización desde el punto de
vista del código pues con el mismo tipo o de la misma clase. Esto se
podría representar en un diagrama donde se incluyera o se representara la
dinámica del funcionamiento, por ejemplo cualquiera de los dos diagramas
de interacción que se utilizan, el diagrama de secuencia o el diagrama de
colaboración se representaría no con la cardinalidad porque en esos
diagramas no se está representando la cardinalidad pero sí de esta forma
indicando que es un número variable de elementos todos del mismo tipo. En
realidad esto en estos diagramas se representa así con una caja inscrita o
descentrada dentro de la otra. Bien, insisto en que este concepto se
utiliza en cualquier parte tanto en el análisis cuando queremos
representar los objetos conceptuales y la información que se requiere y
que se utiliza en el funcionamiento para describirlo o bien también cuando
lo traducimos al diseño detallado que es el funcionamiento que va a
realizar el código o el que se realiza con el código. En cualquier caso
este es la idea de lo que significa un multiobjeto. Un multiobjeto no es
más que una agrupación de elementos todos del mismo tipo o con la misma
información, cada una instanciada o especializada en el valor concreto que
contiene cada uno de esos elementos de una colección. De acuerdo a ese
concepto de agrupación de elementos todos del mismo tipo o de la misma
clase que es al que hemos llegado con denominado el nombre de multiobjeto,
ese concepto al traducirlo a código se le puede dar o necesariamente se
maneja dándole una estructura concreta dependiendo de cuál sea el
lenguaje utilizado o el entorno en el que estamos implementando ese objeto,
ese concepto del multiobjeto. Esa estructura será alguna de las
primitivas, estructuras primitivas que tiene previsto el lenguaje o ese
entorno. Por ejemplo en Java podremos denominarlo desde Collection, Map,
Array, List, ArrayList, etc. Según demos esa estructura en el código,
insisto, a estos multiobjetos podremos hacer con ellos o en el manejo de
esos elementos lo que nos permitan los métodos o las funciones primitivas
de esta estructura que le hemos dado. Podremos hacer una búsqueda, podemos
agregar un elemento al conjunto de elementos según esa estructura que
tenemos definida sin embargo obviamente no nos da la responsabilidad que se
le asigna a este multiobjeto respecto al contenido de cada uno de esos
elementos si no sólo puede manejar los elementos que constituyen esa
estructura. Como digo, según sea la estructura que hemos definido podremos
añadir o podemos quitar un elemento o podemos ordenar dependiendo siempre
de cuál es la estructura de código, de software que hemos dado a esta
agrupación o colección de elementos todos del mismo tipo. Hay veces que
se requiere esa estructura contenerla en un determinado recipiente, lo que
denomino un contenedor por diversos motivos. Uno de ellos puede ser
simplemente encapsularlo y tenerlo agregado, los elementos de esa
colección en el contenedor. En otras ocasiones es necesario hacer aún
más cosas como hacer ordenación, hacer búsquedas, manejar la estructura
y la forma en la que están los elementos de la estructura en esa
colección según la estructura que le hayamos dado. Dependiendo de que sea
uno u otro motivo, podemos asignarle en el caso de que sea conveniente un
contenedor, es decir, un objeto que contenga a los elementos de ese
multiobjeto o al multiobjeto en sí, lo cual al ser un miembro componente
de él a ese contenedor lo único que le da derecho o posibilidad es de
acceder a esa estructura y de realizar operaciones con la estructura, no
con su contenido, es decir, no con los elementos que tiene. En otro orden
de cosas un caso especial de esos contenedores sería lo que llamamos
catálogo. Los catálogos son un contenedor más pero su aplicación es que
además tenga otra serie de funcionalidades adicionales a un contenedor sin
más. El catálogo es un contenedor que puede o está pensado para hacer
otras cosas adicionales. Por ejemplo, en el caso de las descripciones de
cada producto y en concreto el de los precios de la colección de productos
que tenemos a la venta, eso sería la colección. Insisto, se define por su
cardinalidad en un diagrama estático como pueda ser este. En algunas
ocasiones lo que queremos hacer es búsquedas, ordenaciones, órdenes de
los distintos elementos de esta estructura y hay que desarrollar métodos
específicos para realizar ese tipo de operaciones. En determinados casos a
ese contenedor se le denomina catálogo. La idea es, como en este caso, que
tenemos que consultar los precios de los distintos productos que están a
la venta cuando se venden y cuando se seleccionan esos productos para hacer
una venta concreta. En la vida cotidiana, y en esto se referiría al
concepto de lo que se usa en el modelo de dominio, podríamos tener
apuntados los precios en distintos sitios formando una colección y no es
nada lógico tenerlo, por ejemplo, en hojas y cada hoja tenerla por un lado
para consultar cuál es el precio de un determinado artículo que se está
vendiendo. Sino que es mucho más conveniente para manejarlo, encuadernarlo
o meterlo en una carpeta todos los precios de cada uno de los ítems que se
están vendiendo de manera que la consulta sea posible o se facilite esa
consulta. Y ese es el concepto de catálogo. De manera que multiobjetos
podemos utilizar de muy diverso tipo y en numerosas ocasiones y es muy
frecuente utilizar tanto en el modelo de dominio, en la representación de
cómo funciona algo, utilizar estos multiobjetos que, insisto, se definen o
se representan mediante esa cardinalidad. Pero en muchas ocasiones también
nos interesa inscribirlo, ese multiobjeto o los elementos de esa
colección, inscribirlos en un contenedor. No siempre el contenedor va a
ser un catálogo. Por lo general, el contenedor lo que tiene es datos
adicionales que complementan los elementos del multiobjeto y que tienen una
significación conceptual, en este caso de cohesión, respecto a que la
venta contiene todos los elementos que se han vendido y además otra serie
de características, atributos que lo están representando. O bien también
necesitamos incluir funcionalidad adicional para manejar precisamente esta
estructura, más allá de las posibilidades que puede dar la estructura de
código que le podamos dar a los elementos de este multiobjeto. En este
caso, en el modelo de dominio, efectivamente aquí no aparece nada, no
aparece más métodos porque en el modelo de dominio los objetos
conceptuales no se están representando las responsabilidades funcionales
que se le están asignando más que sólo se representa su contenido
estático y no todo él, parte de él, por ejemplo. Esto no se
representaría pero a lo que voy es que en este caso la descripción del
producto forma parte de una información que está compartida con otros
elementos o casos de uso dentro del funcionamiento global de la
aplicación, por un lado. Por el otro resulta que tiene una exigencia de
persistencia, esto es necesario almacenarlo de manera persistente en algún
sitio al que se pueda acceder en determinadas circunstancias y necesidades.
Y aunque es una construcción estrictamente de código, pues esto además
de todas esas funciones que aquí no aparecen, además debe aparecer el
vínculo, el nexo para que permita acceder a un elemento externo mediante
un mecanismo estrictamente de código de manera que pueda acceder al lugar
de almacenamiento, vamos a llamarlo físico, el elemento externo de apoyo y
pueda hacer las operaciones de mantenimiento. Generalmente, precisamente a
estos catálogos que están utilizándose en estos elementos compartidos
que además requieren persistencia, etcétera, etcétera, parte de esa
funcionalidad muy relacionada precisamente con este enlace hacia el
exterior es lo que denominamos las acciones o funcionalidades cruz. La de
crear, la de recuperar, la de actualizar y la de borrar algunos de los
elementos de la estructura. Es decir, este catálogo precisamente tendrá
la responsabilidad cuando lo implementamos en código de contener esos
métodos que implementan precisamente estas operaciones. Estas operaciones,
digamos, in situ, en local, en la memoria y estas operaciones también a
través del adaptador que es precisamente este enlace que he dicho aquí. A
través de ese adaptador que implementa esas mismas operaciones pero
haciéndolas directamente en el elemento externo o en la zona de
almacenamiento que nosotros hayamos elegido. Esa zona de alojamiento puede
ser cualquiera, puede ser una base de datos o puede ser un sistema de
información web o pueden ser unos ficheros que consideraremos externos o
por lo menos ajenos a la funcionalidad que estamos implementando. Porque
siguiendo esta estrategia de fijarnos estrictamente en la funcionalidad que
estamos implementando, bien sea en el análisis para entender cuáles son
los requisitos, cuáles son las necesidades o bien sea en el diseño
detallado para realmente implementar esa forma de funcionar, pues no entra
dentro de esa funcionalidad la de ver cómo se gestiona y se maneja el
almacenamiento. Y por eso lo consideramos una cuestión externa. No quiere
decir esto que al ser externo, considerarlo externo no se tengan que
implementar todos los adaptadores y todo el código que tiene como
responsabilidad o cuya acción es el acceso a la base de datos o a los
ficheros o a las tablas Excel o a los ficheros XML, en fin como queramos
almacenar nosotros los datos y gestionar esa organización del
almacenamiento. Eso es una funcionalidad aparte que posiblemente tengamos
que hacer al final o establecer cuáles son las interfaces o las fachadas
de conexión, pero de la que no nos estamos ocupando ahora. Porque de lo
que nos estamos ocupando en este momento es de cómo manejar los distintos
elementos de esta colección. Insisto, una cosa es el multiobjeto, otra
cosa es si necesitamos para manejarlo ese multiobjeto, bien sea por
cohesión o por integrarlo con otra información, con un contenedor, o bien
sea que para manejarlo y para incorporar toda la funcionalidad que vayamos
a necesitar e incluso la conexión con elementos externos, etc. Lo que
necesitemos sea un contenedor pero de tipo catálogo. Así que un catálogo
no es nada del otro mundo, es algo muy frecuente pero sólo está
justificado en determinados casos. Es algo más que un contenedor y tanto
catálogo como contenedor hacen referencia a qué necesidades y la manera
que tenemos para manejar los elementos que forman parte de un multiobjeto.
Tenga la estructura de código que pueda tener. Da lo mismo para manejarlo
o bien tendremos el código de las funciones primitivas de esa estructura
que le hayamos asignado o si necesitamos más pues necesitaremos un
contenedor que implementará esas responsabilidades o funciones adicionales
que no nos dan las primitivas o un catálogo que es un contenedor que está
pensado para incluir una funcionalidad bastante más específica que se
refiere a estas operaciones cruz, a posiblemente la conexión con elementos
externos o zonas de almacenamiento, etc. Digámoslo así o con cierta
intensidad y para eso el concepto más apropiado es de encerrarlo dentro de
un catálogo e implementar precisamente esa funcionalidad que vamos a
necesitar en ese tipo de estructura, la estructura de catálogo. Bien,
espero haber ampliado la información y las explicaciones y que sean de
utilidad para el uso de catálogo, su diferenciación con un contenedor
normal de los multiobjetos y que es un multiobjeto y la necesidad de ese
concepto de aglutinar los elementos, distintos elementos que necesitamos
manejar todos del mismo tipo con una información igual.