La informática nació como respuesta a las diversas
necesidades de gestión de datos (o información), ya sea para ordenarlos,
compararlos, almacenarnos o procesarlos de diversos modos. Esto es un hecho que
parece que ha tenido un fuerte impacto a través de generaciones de
desarrolladores de software. Me refiero a enfocar un sistema a partir de los
datos que procesa en lugar de las operaciones que hace.
Es común ver como se inicia la planeación de un sistema,
diseñando tablas de base de datos, y las relaciones que tienen entre ellas,
incluso antes de saber que podría hacerse con los datos que almacenan estas, o
incluso tener claro los flujos de las operaciones requeridas. Los motivos para
comenzar en este punto en particular suelen ser variados, entre los cuales
podrían estar los siguientes:
- Es sencillo: Realmente no requiere complicidad el diseño de tablas como diagramas o incluso directamente mediante diseñadores gráficos de base de datos. Un diagrama de base de datos es, además, fácil de entender a simple vista.
- Sabemos que vamos a tener datos: Es un hecho, haga lo que haga nuestro sistema, seguramente guarde información (en algún lado), y las base de datos suelen ser un lugar idóneo.
- Es uno de los límites de nuestro sistema: Generalmente una vez que estamos en la base de datos, está ya no se conecta a ningún otro punto de nuestro sistema, sino que los otros componentes son los que se comunican con la base de datos (de allí que use el término “limite”).
- Además la conclusión del diagrama es un aporte a la construcción del sistema: Cuando términos el diagrama, en casi todos los servidores, se puede convertir casi directamente en scripts SQL, si es que este proceso no se hace simultáneamente, (crear el diagrama y a la vez las tablas en la base de datos).
Sin embargo el enfocar el diseño a través de la creación de
la base de datos, es bastante limitado,
precisamente porque se fija solo en un aspecto del sistema, es decir solo pone
énfasis en los datos. Dicho enfoque
tiene los siguientes inconvenientes:
- Centrarnos en los datos, nos impide abstraer correctamente el problema, sobre todo si hacemos esta parte al principio del desarrollo. Dicho de otro, como guardamos nuestra información, es un concepto demasiado de “bajo nivel”, para la abstracción que necesitamos al comienzo del diseño. (Por ejemplo: cual es la Primary Key, de qué tamaño deben ser los campos, puede que no sea tan relevante, como el que tiene que hacer el sistema).
- Las relaciones entre las tablas son limitadas: De hecho son solo tres, de uno a uno, de uno a muchos o de muchos a muchos, según el número de elementos de cada tabla que se ven involucrados en dichas relaciones. En cambio el enfoque orientado a objetos, tiene relaciones más ricas, como relaciones de herencia (lo que favorece la abstracción) o intercambio de mensajes entre objetos.
- Además, un riesgo adicional es que extralimitemos las funcionalidad de nuestro servidor de base de datos y decidamos que tiene sentido que la lógica de negocio este en los procedimientos almacenados, con lo que desde allí estaremos perdiendo todas las ventajas de un lenguaje de programación orientado a objetos.
- Los diagramas de base de datos solo representan datos, es decir no representan ningún comportamiento.
El enfoque más idóneo es comenzar el diseño de los objetos o
las clases de los que se va a constituir
nuestros sistemas. Generalmente al comienzo del diseño, tenemos una idea de
cómo queremos hacer las cosas, dicha idea no tiene que estar completa, y cuanto más avancemos en ella, mas compresión
tendremos sobre la misma. Podemos ir reduciendo el nivel de abstracción según
los necesitemos. Igualmente podemos usar relaciones de objetos, ya sea
de jerarquía (herencia) o de contención (un objeto contiene a otro, o a
varios). Y lo más importante, se comprende que los datos, van de la mano de las
operaciones (funcionalidad), y se diseña el sistema de dicha forma.
A veces he visto diseños de sistemas en los que se crea un
“modelo” que contiene datos, pero ningún comportamiento, dejando la funcionalidad
en otro conjunto de Modulos, con una programación más o menos estructurada,
pero carente de ningún tipo de orientación de objetos. Justificándose este
comportamiento con frases como “Los datos deben estar separados del código” o
semejantes, completamente sacadas de contexto. La verdad es que esta forma de
programar rompe completamente con el paradigma de la programación orienta a
objetos, en que los datos y su comportamiento forma un todo inseparable (este
“vicio”, tiene un nombre y es “Modelo de dominio anémico”, es un antipatrón de
software).
Evidentemente comenzar el diseño por los objetos también
tiene sus problemas, por ejemplo el diseño de diagramas UML es más complejo. Aunque
pudieran llegar a parecer en principio sencillos, se pueden llegar a complicar
mucho, son difíciles de entender por personas sin preparación (digan lo que
diga), y casi siempre se convierte en un estorbo y se desactualizan llegado a
un punto en el proyecto. La única manera de mitigar esto es que la conversión
de UML a código y viceversa sea simultánea y al momento, y que de alguna forma
las herramientas muestren información útil de forma gráfica. Las herramientas
deben ser útiles al momento de programar, de forma que el UML esté integrado
como parte de la programación, y no como un mero elemento documental.
Una vez que tengamos diseñado nuestras clases, con el
comportamiento y los datos (o atributos) que estas poseen, podemos comenzar a
pensar en cómo debemos persistirlas, y aquí entra, ya por fin, nuestro servidor
de base de datos. De esta forma obtendremos un sistema más consistente y sin
duda, mucho más escalable.
No hay comentarios:
Publicar un comentario