Ahora, un ejemplo más practico:

Hide image

Imagen 2: Típica aplicación que me dará dolores de cabeza cambiar. Me preocupa saber que código hay detrás y que rayos hará...

Pues aunque suene increíble, este tipo de “código” es muy común.. El que no lo hagamos en el editor de texto no lo hace menos código. Un programador aún sin entrenamiento formal tiende a colocar el código escrito que se repiten en funciones o clases.

Pero cuando se trata de componentes que se ven en diseño parece que no ve que puede HACER LO MISMO.

Los controles de acceso a datos cumplen con 1) Cosas que no se ven 2) Cosas que los demás cambian 3) Cosas que SEGURAMENTE cambiaran. Mala idea poner MUCHO de eso en distintos lugares porque: “Más fácil cambiar mientras menos lugares haya que cambiar”. De ahí que muchos usan los TDataModules, porque es una buena idea.

Por otro lado, el TDataSource es distinto. Aunque parece cumplir con los mismo defectos que los TDataSet y sus descendientes, resulta que 1) Realmente no hace NADA … solo mapean datos a controles 2) Interfaza a los TDataSet 3) Cambiar de un TDataSet a otro no altera el FUNCIONAMIENTO de los TDataSource. Y resulta que las cosas que cumplen con estos 3 elementos son buenos SIMPLIFICANDO EL CAMBIO.

Tener muchos TDataSource realmente no es problemático y al contrario es útil para posicionar los elementos de los formularios, los informes y declarativamente, asignar el enlace a datos. TDataSource es un buen chico: No causará líos cuando lo demás cambie.

(PS: TDataSet es una clase muy bella: Presenta de forma unificada una colección de filas y columnas y la manera de alterarlos. Sin embargo, el enfoque esta en como la proliferación de muchos componentes que DEPENDEN de otros que tienen implementaciones DISTINTAS que cambia en el tiempo se debe evitar. TDataSet esta muy bien, que nos cambien todo el tiempo de tecnologías de acceso a datos es el punto a notar).

El problema radica en que, en todo tutorial y ayuda, siempre vemos los TDataSet y TDataSource juntos.

Pero eso no tiene que ser así. Si los cambios se simplifican disminuyendo la cantidad de los componentes/código que SEGURAMENTE va a cambiar, que tal si lo hacemos así:

unit Unit2;

uses SqlExpr, DB;

interface

type
  TDataManager = class(TObject)
  private
 
  protected   
    function OpenConnection(): TSqlConnection;
 public 
   
   function ExecuteAsDataSet(lcSql : String): TSQLDataSet ;
   function ExecuteNoDataSet(lcSql : String): Integer ;
 end;

implementation

end.

Pues ahora tenemos UNA SOLA CLASE que implementa el acceso a datos. Es una facilitadora del cambio: un solo lugar donde chequear. Una interface que esconde lo que realmente no se necesita (por ejemplo, la conexión, la necesita ExecuteAsDataSet, pero no se necesita por fuera de la clase... no, realmente no se necesita).

Fácil de cambiar el comportamiento (OpenConnection puede crear la conexión cada vez que se llama, obtenerla de un componente dentro de un TDataModule o usar un sistema de pooling para mejorar rendimiento en ambientes exigentes, sin alterar el funcionamiento externo).

Luego un formulario base que enlace los TDataSource, de ahí, una función que cargue la clase de acceso a datos, y conectar el TDataSet(cualquiera) a los TDataSource. Si fuésemos a cambiar de dbExpress a ADO, seria cambiar los tipos de datos de vuelta y el código interno de crear y conectar controles…implica igual cambio, pero es MUCHO mejor que alterar múltiples formularios (porque la idea es que quitamos todos los TDataSet de encima de los formularios). Es un gran avance hacia un código más administrable y flexible… Y luego, hasta podríamos pensar en soportar varias tecnologías de acceso a datos… luego, aún más elegante, no llamar el acceso a datos en los formularios, sino solo tratar con clases abstractas, de interface con la funcionalidad del negocio - como hace Bold / ECO, presentes en las versiones Architect de Delphi -(recuerde: este tipo de clases son buenos chicos: facilitan el cambio); y es más fácil pensar en estas metas porque es menos descabellado alterar UNA clase que muchos formularios, además, si cambiamos los tipos de datos el compilador de Delphi nos dirá donde hay que hacer los cambios...

¿Y por qué detenerse ahí? Y que tal si en vez de tener cadenas de SQL diseminadas en MUCHOS lugares los ponemos en un solo lugar (una lista de constantes, una base de datos local, un archivo de texto o XML)…¿o crear una clase que construya el SQL en base a una lista de criterios?

El punto es que entender el cambio ayuda a construir mejor código, que tiende a abrir las posibilidades y permite reaccionar más fácilmente a los constantes ires y venires del mundo tecnológico.

Estas cosas es lo que se llama comúnmente la lógica del negocio…o sea si es un programa de facturación, son los códigos y componentes que hacen SOLAMENTE facturación, no pintar cuadros, no imprime informes, no manda correos. Un programa de análisis numérico, es el código que hace el análisis.

Para evitar que las cosas que SEGURAMENTE van a cambiar cambien lo que debemos EVITAR que cambien (=no debería alterar la lógica de la aplicación), pues debemos dividir las responsabilidades. Ejemplo:

function TForm1.CalcularSalario: Double;
begin
  result:=EditBaseSalario.Field.AsFloat*30;
end;

Es un código que no debemos permitir que se cambie. O sea, la aplicación DEBE calcular el salario. ¿Cómo podría arruinarse el código? Bueno, tal vez el campo de la base de datos cambia, tal vez cambiamos de controles enlazados a datos (nos gusto una librería con su propia versión de un Edit...). Pusimos un MessageBox para informar al usuario pero luego queremos pasar la aplicación al Web, una aplicación externa debe conectarse a la nuestra en tiempo real a través de COM o de un Servicio Web. Ahora, no solo el código hay que cambiarlo, será COSTOSO hacerlo. Y si existe mucho código de este tipo existirá la tentación de hacer “truquitos” y no hacer las cosas bien.

Sin embargo algo como:

function TEmpleado.CalcularSalario( BaseSalario : Double ): Double;
begin
  result:=BaseSalario*30;
end;

Ya es mejor. Y como estoy inspirado, una mejora más!

function TEmpleado.CalcularSalario( BaseSalario : Double ): Double;
begin
  result := BaseSalario * DiasEnMesContable;//Eliminado el número mágico. Ahora compila los martes 13 ;)
end;

Conectar clases es fácil, y más cuando las clases son tan independientes, que no saben si se conectaron con un formulario o un servicio Web.

Si colocamos el “nucleo” de nuestra aplicación en clases bien definidas que hacen solo su trabajo (y el de nadie más), y usamos parámetros que no sean controles ni clases que no tengan que ver con la lógica de la misma (en la medida de lo posible, mejor pasar estructuras o clases informativas o simples variables), lograremos un sistema más inmune a los cambios de arquitectura, de base de datos o de controles visuales, e incluso a los propios.

Y no tuvimos que reescribir la aplicación desde CERO!  Woow! Santos ahorros de tiempo y dinero!

Esto que acabe de hacer se llama refactorización que en pocas palabras es mejorar el código fuente sin alterar su comportamiento (= no introduce nuevas características y claro, no introduce más errores!). De paso, asegure que el código del cálculo del salario sea reusable, y podemos luego llamarlo desde un servicio Web, una página de HTML, una página WAP para celulares, etc...

Pueden aprender más sobre este tema leyendo este artículo (inglés) de Jim Cooper. Aunque la técnica de refactorizar se puede hacer de forma manual, como acabo de hacer, con Delphi 2005 es mucho más fácil!

Y no solo es fácil de cambiar, es fácil de portar. Portar a Linux o a .NET, código de este estilo, es fácil. Integrar es fácil, solo necesitamos colocar tecnologías puentes como SOAP. Ok, cambiar de componentes visuales puede dar algo de dificultad y es muy probable que se gaste unas buenas semanas, incluyendo el esfuerzo en volver a probar el código.

Tal vez, exista un componente que hace algo importante, como presentar informes… Pero es algo que se puede solucionar cambiando de componente. No una solución ideal, pero pragmática, al fin y al cabo, nuestro trabajo no era hacer el reporteador, es hacer facturación.

Una posible excepción, podríamos pensar, son los mismos controles visuales. Por ejemplo, ¿que tal si nuestro trabajo no es un sistema de facturación sino crear controles, como un control de menú, que estaba en Win32 y ahora debe estar en Delphi.NET con Winforms o ASP.NET? ¿No porta, verdad?

Bueno, una forma de separar responsabilidades es tratar de ver el problema de la manera más simple, de entender que realmente es lo que se debe de hacer, no como.

¿Que hace un menú? Es algo como una estructura de árbol. Debe hacer clic, debe mostrar iconos…bueno todos sabemos que hace un menú.

Lo importante: Debe hacer lo mismo no importa la plataforma, ni el entorno. Un menú es buen menú, si hace lo que un menú tiene que hacer.

Estos meses estuve probando entre unos 5 diferentes menús de distintos fabricantes para ASP.NET de un sistema ERP que estoy haciendo. Al final nos quedamos con una librería, básicamente, porque nos salía económico el paquete. Lo más molesto es que me tocaba recodificar los menús cada vez que probaba uno...mucho código. Eso me harto, e hice mi propia representación virtual de un menú: Arme una colección con la misma estructura de menú, con las propiedades que todo menú tiene y así por el estilo. Luego, para cada API de estas librerías, UN SOLO CICLO armaba en tiempo de ejecución el menú, ajustado a la forma particular de cómo cada sistema quería hacerlo (unos sistemas requerían armar un archivo XML, otros tenían un API OO, otros de forma mixta). Todo el trabajo no gasto más de 4 horas y ahora, ya que el menú es virtual, lo puedo pasar de plataforma y de controles sin gastar más de 1 día de “Duro” trabajo (cambiando los colores o ajustando los efectos visuales, principalmente), y por ahí también aproveche la clase para fabricar un navegador estilo árbol para el sitio, de ahí a un mapa del sitio es solo un pequeño paso. De hecho, usar representaciones virtuales de los controles gráficos es lo que terminan haciendo los que fabrican componentes, como los grids, reporteadores y demás.

Por eso es que esas empresas logran tener productos a otras plataformas y herramientas tan rapido. Usted tambien puede. El resto de trabajo es pura carpinteria (que no es que la carpinteria sea fácil... es solo un poco mas predecible)

En conclusión, si protegemos el código de la lógica de los negocios (que es la CLAVE de nuestro programa: Todo lo demás es añadidura) estamos protegiendo nuestra libertar de cambiar … evitando que lo demás nos cambie.