BeforeFieldChange y AfterFieldChange. Parte 1.

En ocasiones, cuando utilizamos conjuntos de datos en Delphi, escribimos código para ejecutarse en respuesta al cambio de valor de un campo, generalmente cuando tal cambio ocurre como parte de una captura de datos. Delphi permite hacer esto con el evento OnChange de la clase TField y con el evento OnDataChange de la clase TDataSource.

Pero estos presentan dos grandes desventajas.

Desventaja #1: Mienten.

Se disparan siempre que hay asignación de valor al campo, no solamente cuando éste cambia de valor. Para entender la diferencia, considere que tenemos un campo de tipo entero con un valor de 5 en el registro actual y ahora le asignamos el resultado de la suma 3 + 2, o bien el usuario captura nuevamente 5 en un cuadro de texto que está asociado a ese campo. En cualquiera de estos casos, ¿cambió el campo de valor? La respuesta es no, sin embargo se ejecuta el código de esos mentirijillos eventos “change”. Esto resulta, bajo la mayoría de los casos, en un procesamiento innecesario que puede consumir pocos o muchos recursos (procesador, memoria, tiempo), dependiendo de lo que haga el manejador de evento que hayamos programado.

Desventaja #2: Ocultan el pasado.

Una vez que el campo cambia, ¿cómo podemos saber qué valor tenía previamente? Puede ser que, tras ser modificado el valor del campo, necesitemos realizar algo en especial con el valor que tenía anteriormente.

Ni siquiera el evento OnValidate de TField se salva de esas dos desventajas. Alguna vez me vi utilizando una variable auxiliar para guardar el último valor asignado de un campo, con el fin de verificar si éste realmente había cambiado de valor o de ejecutar una tarea que requería el valor previo como parámetro.

Abriendo un pequeño paréntesis, estoy seguro que en algún momento Delphi contará con un manejo nativo, rico y muy eficiente de entidades de datos, a través de clases Row o Record cuyas instancias representen las filas de un cursor, como ha sucedido ya en otras tecnologías de programación y como de alguna manera se intentó con ECO, y donde cuestiones como las planteadas aquí y otras menos ordinarias (como saber si el valor de un campo está siendo asignado o no) estén felizmente resueltas. Cuando el fabricante se vaya a poner a trabajar en ello, me gustaría muchísimo tener algún tipo de participación, pues bajo el desarrollo de mi marco personal he venido asentando una serie de mecanismos y conceptos que siento deben ser considerados.

Por el momento y regresando al tema, podría ser buena idea que la clase TDataSet tuviera un par de eventos adicionales llamados BeforeFieldChange y AfterFieldChange, ambos disparados cuando un campo realmente cambie de valor. El primero justo antes de que ocurra el cambio, e informando mediante un parámetro Variant cuál es el valor que está por ser asignado. El segundo justo después de ocurrir el cambio, e informando mediante un parámetro Variant cuál es el valor que tenía previamente.

De esta forma todas las clases descendientes de TDataSet heredarían esos nuevos eventos, permitiéndonos usarlos con cualquiera de los componentes de acceso a datos nativos o de terceros.

procedure TDataModule1.DataSet1BeforeFieldChange(
  Field: TField; NewValue: Variant);
begin
  { Verificamos qué campo está por cambiar (Field)
    y cuál será su nuevo valor (NewValue),
    elevando una excepción si queremos impedir el
    cambio o realizando alguna tarea específica }
end;

procedure TDataModule1.DataSet1AfterFieldChange(
  Field: TField; PrevValue: Variant);
begin
  { Verificamos qué campo acaba de cambiar (Field)
    y cuál era su valor anterior (PrevValue),
    realizando alguna tarea específica }
end;

En Delphi, como en muchos otros lenguajes, podemos redefinir métodos que previamente han sido declarados como virtuales. Esto nos permite extender las capacidades de una clase, creando una derivada con dichos métodos reimplementados por nosotros mismos. Eso es algo de lo más común. No obstante, pocos son los que se han atrevido a tocar el tema de la redefinición de clases, clases virtuales o herencia insertada, como si se tratara de un tabú en la POO. Con esos términos no acuñados me refiero a la capacidad de ampliar una clase sin tocar su código fuente, consiguiendo que sus actuales descendientes adquieran en automático la nueva herencia al ser compilada la aplicación que los utilice. O, dicho de una manera burda, insertar herencia adicional en medio de una jerarquía de clases.

Si las clases Delphi fueran redefinibles en ese sentido, podríamos agregar los eventos BeforeFieldChange y AfterFieldChange a la nativa TDataSet, sin esperar a que Embarcadero lo haga y sobre todo respetando el código fuente de la VCL. Logrando así que todas las clases de conjuntos de datos nativas y de terceros (TClientDataSet, TADODataSet, TIBTable, TMemoryTable, TMDOQuery, etc.) que utilicemos en nuestros proyectos cuenten con dichos eventos, sin necesidad de crear una clase derivada para cada una escribiendo código repetido. Lo más cercano que Borland estuvo de ello fue la inclusión de los ayudantes de clases, pero éstos dejan mucho qué desear.

Imaginemos que ya estamos en el mundo justo y feliz que a Object Pascal le corresponde tener, y que podemos escribir algo como esto:

Uses
  DB;

Type
  TFieldAfterChangeEvent = Procedure (
    Field :TField; PrevValue :Variant) Of Object;

  TFieldBeforeChangeEvent = Procedure (
    Field :TField; NewValue :Variant) Of Object;

  // Ampliaremos a TDataSet
  TDataSet = Class Override
    Private
      FAfterFieldChange :TFieldAfterChangeEvent;
      FBeforeFieldChange :TFieldBeforeChangeEvent;
    Protected
      { Versión "superior" del método virtual
        SetFieldData, usada para implementar el
        disparo de los eventos BeforeFieldChange y
        AfterFieldChange.  Top significa que, para
        todos los descendientes de TDataSet, se
        ejecutará esta versión del método como si
        fuera una redefinición por encima de las
        ya existentes. }
      Procedure SetFieldData (Field :TField;
        Buffer :Pointer); Top;
    Published
      Property AfterFieldChange
        :TFieldAfterChangeEvent
        Read FAfterFieldChange
        Write FAfterFieldChange;
      Property BeforeFieldChange
        :TFieldBeforeChangeEvent
        Read FBeforeFieldChange
        Write FBeforeFieldChange;
  End;

Estoy consciente de que una característica como ésta de la redefinición de clases presentaría varias repercusiones a considerar, pero es posible que en muchos casos se trate de situaciones salvables en las que los beneficios de programación tengan mayor peso que las medidas de control subyacentes que haya que tomar. En todo caso, si nuestra falta de experiencia en una tecnología prácticamente inexistente nos impide ver con claridad las vicisitudes que vendrían si intentáramos crear ésta, al menos deberíamos empezar por debatir el tema y sacar en claro lo que sí podríamos hacer y lo que no deberíamos hacer. ¿No lo creen?

En la segunda parte de este artículo entraremos de lleno a la práctica, implementando estos dos nuevos eventos en una clase derivada de TClientDataSet. Estén pendientes de ello.

Mientras tanto arrojen sus comentarios.

Un abrazo natural y eficiente.

Al González.