[[Al González]]

¡Buen día a todos!

Interesante encuesta. Voté por la penúltima opción.

Me llamaron la atención dos de los planteamientos:

1. Si la herencia tendría sentido si se tuviera que implementar a partir de cero el código de cada método en clases descendientes.

La respuesta es si, como ya se ha mencionado, por la capacidad que aún (en ese pobre estado) tendrían las instancias de clases descendientes para tratarse polimórficamente (una manzana puede tratarse genéricamente como una fruta).

2. Si una clase es abstracta y no instanciable por declarar (o heredar) un método abstracto.

Se entiende que una clase abstracta no puede ser instanciada porque se trata de una definición parcial de la implementación de un objeto, por lo tanto un objeto instanciado bajo una clase abstracta sería un objeto incompleto (como una manzana mordida, jeje , aunque he escuchado hablar de una manzana mordida que está más que excelente ). Obligar a implementar el método abstracto en clases descendientes, es una manera de garantizar que no se creen instancias de objeto con implementaciones incompletas. No obstante, Delphi permite la creación de objetos bajo clases que tienen métodos abstractos, reportando el compilador una advertencia al respecto cuando la expresión de instanciación lleva explícitamente el nombre de la clase. Y es que en ocaciones, la falta de implementación de un método no significa que la clase esté incompleta, sino que se trata de una característica que el objeto instanciado simplemente no tendría (la manzana no tiene etiquetita de distribución). Sin embargo, lo correcto en esos casos es definir el método sin código (sólo Begin y End), en lugar de Abstract.

Por otro lado, me permito agregar algunas experiencias algo especiales que he tenido con Programación Orientada a Objetos (POO) en Turbo Pascal y Delphi.

Por varios años utilicé Turbo Pascal 5.5, y me enteré de que éste manejaba objetos cuando ya llevaba tiempo usando la versión 6.

En alguna época abstracta , me di a la tarea de reimplementar varias de las clases de la biblioteca Turbo Vision (aquella que venía con Turbo Pascal 6 y 7) para que todos los componentes derivados de TView (el nostálgico TView ) desplegaran su contenido en modo gráfico (en lugar de modo texto ASCII). Abandoné el proyecto cuando supe que existía un Turbo Pascal para Windows .

Ya en Delphi, lo primero que aprendí de objetos, fue que las variables de este tipo eran punteros implícitos a los bloques de memoria donde se guardan las instancias (no me imagino escribiendo en pascal de Delphi Rejilla^.DataSource^.DataSet^.Refresh;).

Después de un par de meses con Delphi, descubrí la manera de cambiar en tiempo de diseño la clase de un componente agregado a una forma. Por ejemplo, si después de agregar un TEdit en una forma y haberle establecido valores en varias de sus propiedades, decido cambiar el componente por un TComboBox, en lugar de quitar el componente TEdit, agregar un TComboBox y volver a establecer las propiedades, lo que hago es mostrar la forma como texto (Alt+F12), cambiar ahí la declaración del objeto "TEdit" por "TComboBox", vuelvo a mostrar la forma (Alt+F12) y guardo.

Pero cambiar la clase de un objeto en tiempo de ejecución, requirió de conocer qué es exactamente una instancia de objeto y que guarda en su interior. Los primeros cuatro bytes del bloque de memoria de un objeto, osea de la instancia, es el identificador de la clase (la dirección de memoria donde está la definición estructural de la clase). Por lo tanto, es sumamente sencillo cambiar la clase de un objeto en tiempo de ejecución, tratando a la referencia objeto como un valor de tipo PClass (puntero a clase). Por ejemplo:

Type
  PClass    = ^TClass;
Begin
  Edit1 := TEdit.Create (Self);
  PClass (Edit1)^ := TMiEdit;

Otro truco que también emplea molde de tipo (type cast), es el de acceder a un método protegido (Protected) de una clase, desde una unidad distinta a la que define esa clase:

Type
  TMiEdit = Class (TEdit);
Begin
  TMiEdit (Edit1).KeyDown (vk_Return, [ssCtrl]);

Pero quizás el truco de molde de tipo más chapucero sea el de acceder a los campos privados de un objeto:

Type
  { Tipo Molde de Acceso a TIBTable }
  TMoldAcceTIBTable = Class (TIBCustomDataSet)
    Private
      FSystemTable :Boolean;
      FMultiTableView :Boolean;
      FMasterLink :TMasterDataLink;
  End;
Begin
  TMoldAcceTIBTable (IBTable1).FMasterLink.Free;

(NOTA: Manéjese con cuidado. La clase que hace de molde de tipo debe ajustarse a las modificaciones que el fabricante haga de la clase que parcialmente emula.)

Un truco que he encontrado muy útil es el de llamar a un método que por la herencia ha sido tapado (escondido) por uno homónimo en clase descendiente. Consiste en asignar a una estructura TMethod, la dirección de memoria del método escondido y el objeto con el cual queremos que se ejecute (el que será Self dentro del método). Entonces ejecutar el paquete TMethod bajo un molde de tipo que tenga la misma cabecera declarativa del método en cuestión.

Recientemente, he venido observando (y externando en algunos temas) la necesidad de que Delphi cuente con herencia insertada. Así denomino a la capacidad (aún teórica) de que se pueda definir una nueva clase de objeto e insertarla en la jerarquía de otras dos, sin tener que modificar el código fuente de éstas últimas. De tal forma que la nueva clase se convierta en el nuevo padre de la hija y en el nuevo hijo de la padre.

Type
  TMiDataSet = Class (TDataSet) Inserted;
    Public
      Function Permitida :Boolean;
  End;

  — ó —

  TMiDataSet = Class (TDataSet) Inserted For
    TCustomADODataSet, TIBCustomDataSet;
    Public
      Function Permitida :Boolean;
  End;
...
Begin
  If IBTable1.Permitida And ADOQuery1.Permitida Then
    ...  { Si tiene acceso }

La herencia insertada resolvería muchos casos donde, a falta de ella, se tiene que implementar dos o más veces la misma característica en clases que tienen un ancestro común que podría albergar dicha característica de forma centralizada, además de las ventajas polimórficas que esto otorgaría.

Añado que en una ocasión desarrollé una rutina que servía para clonar objetos, es decir, copiar por completo la instancia de un objeto (el bloque de memoria que ocupa). Pero considerando los contadores de referencia que hubiese de sus campos String, Variant, interfaces y arreglos dinámicos. Para ello utilicé la función interna _CopyRecord de la unidad System.pas. Deduzco que _CopyRecord es la función que se llama cuando se realiza una asignación del tipo Registro1 := Registro2, donde los operandos son estructuras declaradas como Record. Observé que _CopyRecord utiliza información RTTI para determinar los desplazamientos y tipos de campos que utilizan contadores de referencia, incrementando en uno dichos contadores cuando se realiza la asignación de un Record a otro.

Finalmente, en la unidad System.pas, justo después de la función _CopyRecord, se encuentra una función llamada _CopyObject. Por su cabecera declarativa, pareciera que ésta realiza una tarea similar a _CopyRecord (de hecho la llama), pero con objetos. Sin embargo, tengo dos dudas al respecto: ¿basta una llamada a _CopyObject para copiar todo el objeto por completo?, y la más enigmática, ¿en qué situaciones emplea Delphi la función _CopyObject?. Objeto1 := Objeto2 es sólo una copia de puntero, Objeto1^ := Objeto2^ es sintácticamente inválida.

¿Dónde se usa _CopyObject?

Como siempre, les envío un fuerte abrazo.

¡Hasta pronto!

Al González .