constantes de classes demasiado estáticas :P

[poyo]

Bueno, les cuento que al final lo resolví poniendo variables de clase.
A la clase base le puse un método virtual llamado "initclassvars" y allí las inicializo todas juntas.
Ese método lo ejecuto or única vez en la registración de mis classes...
De esta manera achiqué CONSIDERABLEMENTE la cantidad de líneas a escribir de unas 1000 a "apenas" alrededor 350. Comparando con lo que hubiese sido lo más lógico: funciones de clase... pero me negaba a escribir taaantas veces lo mismo!
Era eso un Bot que escriba por mí. jejejeje
Nuevamente. Gracias por ayudarme a despejar mis dudas.

--------------------------------------------------------
EDITO: Lo que puse antes fue porque canté victorio de apresurado sin haber hecho las suficientes pruebas!!!!
Eso me pasa por neófito!

Resulta que una clase que hereda de otra clase un "Class Var", hereda exactamente la misma variable... con la misma posición y todo... o sea, la MISMA variable y no otra de similares características.
Es como si fuese una global pero que se accede con la clase como referencia:

TClassEjemplo.Variable := 'valor';

o sea que si tenemos:

Código Delphi [-]
TClassEjemplo = class(TObject)
  public
    Class var cadena: string;
end;

TClassHija = class(TClassEjemplo)
end;

y yo ejecuto:

Código Delphi [-]
TClassHija.Cadena := 'valor nuevo';

Voy a estar cambiando implícitamente el valor de TClassEjemplo.cadena;

Para que cada en una nueva clase REALMENTE sea otra "Class Var", es decir con otro puntero en memoria, esta tiene que ser vuelta a declarar (no existe override, simplemente se declara del mismo modo y listo):

Código Delphi [-]
TClassHija = class(TClassEjemplo)
  public
    Class var cadena: string;
end;

Perdón por el apuro.
Ahora estoy pensando si agrego líneas de declaración de variables o simplemente pongo una función de clase que devuelva un record con todo junto y se acabó

[[Al González]]

¡Hola Poyo!

Aunque quizá hay mejores soluciones (habría que ver el fondo de esta necesidad ), se me ocurre, por ejemplo, el uso de propiedades con índice y tener un arreglo global con todos los valores posibles de la constante de clase.

Desarrollé un ejemplo para ilustrarlo:

Código Delphi [-]
implementation

{$R *.dfm}

Uses
  TypInfo;

Const // Cambiar a "Var" para emular variable de clase en vez de constante
  Cadenas :Array [0..2] Of String = ('X de TA', 'X de TB', 'X de TC');

Type
  {$TypeInfo On}  // Para generarle RTTI a la clase TA y sus descendientes
  TA = Class
    Private
      // Método de lectura de la propiedad
      Function GetX (Indice :Integer) :String;
    Published
      { Declaración base de la propiedad que emulará una constante de
        clase virtual.  Añadir especificador "Write SetX" para emular una
        variable de clase virtual en lugar de una constante. }
      Property X :String Index 0 Read GetX;
  End;
  {$TypeInfo Off}

  TB = Class (TA)
    Published
      Property X Index 1;
  End;

  TC = Class (TA)
    Published
      Property X Index 2;
  End;

Function TA.GetX (Indice :Integer) :String;
Begin
  { Para que la solución sea polimórfica, es necesario consultar en la RTTI
    el índice que tiene la propiedad X para el objeto actual, en lugar de
    usar el índice que llega como parámetro (ver la diferencia comentando
    esta sentencia) }
  Indice := GetPropInfo (Self, 'X').Index;

  { Devolvemos la cadena que corresponde del arreglo global }
  Result := Cadenas [Indice];
End;

procedure TForm1.Button1Click(Sender: TObject);
Var
  A, B, C :TA;
begin
  { TEMA: Emular constante de clase "virtual" mediante una propiedad
    publicada con índice y soportando polimorfismo. }

  { Aunque las tres variables están declaradas como de clase TA, les
    asignamos instancias nuevas de clase distinta }
  A := TA.Create;
  B := TB.Create;
  C := TC.Create;

  { Aunque las tres variables estén declaradas con la misma clase, y a
    todas las compilemos como objetos TA, en tiempo de ejecución el
    programa leerá el valor correcto de la propiedad X para cada objeto,
    según la clase real a la cual pertenecen (polimorfismo) }
  ShowMessage (A.X);
  ShowMessage (B.X);
  ShowMessage (C.X);

  // Liberamos los objetos (usar Try..Finally en un caso real)
  A.Free;
  B.Free;
  C.Free;
end;

Anexo el código en un archivo .zip.

Saludos.

Al González.

[[Delphius]]

Hola poyo,
Me gustaría que nos comentases a que se debe todo. Si en vez de trabajar con ejemplos abstractos nos comentases con mayores detalles sobre tu caso real, tal vez podríamos proponerte alguna otra alternativa o enfoque que puedas considerar.

Si, muy cierto es que si ya tienes bastante código no es bueno cambiarlo, pero quizá si nos compartes más del caso podríamos entre todos ver de que otra manera darle la vuelta y sin que tengas que afectar todo el diseño.

Saludos,

[[Delphius]]

Me gusta el enfoque de Al.
No me imaginaba muchos casos de uso práctico de estos tipos de propiedades... es posible que en este tipo de casos sea de buena utilidad. Y bastante económica por cierto.

Saludos,

[poyo]

Antes que nada, gracias por las ideas, sugerencias y predisposición.

Les cuento la idea.
Quiero implementar una solución a una serie de MUCHISIMOS algoritmos que tengo. Entonces se me ocurrió abstraerlos un poco.
Les cuento cómo es la idea: tengo una clase base (abstracta) y, luego, cada implementación es una clase heredada.
La clase base brinda lo necesario para su registración (plugineo) y consiguiente utilización, además de información, testeo, benchmark y algo más si se me llegase a ocurrir.
La clase base tiene un "resumen" donde las clases herederas, sin ser instanciadas, brindan información para que se pueda elegir cuál de todas se va a usar (instanciar).
El "resumen" consiste en: ID, Nombre, Descripción, Autor, Versión, Tipo de Licencia, Texto de la Licencia y podrían haber muchas más cosas.

La idea de Las constantes fue lo primero que se me ocurrió, pero no funcionó. Era mi primera vez con las constantes de clase pero no funcionaron de la manera que esperaba.
Las Variables de clase tampoco.

Hacer una función por cada uno de los elementos del "resumen" es una locura... imagínense que, en un principio tengo como 40 ó 50 clases para hacer y luego seguro que me espera una tanda más.

La idea entonces era escribir en cuanto al resumen lo menos posible para poder dedicarme a las implementaciones.

Por ahora estoy implementando una solución que, a mi entender, no es muy eficiente que digamos, pero CREO que es funcional:

Código Delphi [-]
TResumen = record:
    ID,
    Name,
    Desc,
    Version,
    Author,
    License,
    LicenseType,
    Help:             string;
 end;

// y en el public de la clase puse:
 Class Function Resumen: TResumen; virtual;

De esta manera hago sólo una función... y un algoritmo es un derivado de otro y sólo cambia el ID/nombre, sólo sobreescribo esta función y hago lo siguiente:

Código Delphi [-]
Class Function Resumen: TResumen;
begin
  result := inherited;
  result.ID := 'NUEVO_ID';
  result.Name := 'Nombre nuevo';
end;

De esta manera heredo el nombre del autor, licencia, etc.
En cuanto adapte el código a esto nuevo les cuento cómo me fué... igual lo tengo bastante verde al asunto.

Espero que se haya entendido.

[[Delphius]]

Hola poyo,
Muchas gracias por confiar en nosotros. Aquí hay mucha gente que te puede ayudar y que sabe un montón (excepto yo... )

Bueno, déjame ver si comprendo, tienes una serie de datos que debes propagar por la herencia, y por lo que parece esta serie de datos posiblemente no sea estática... sino que tal vez pueda crecer más. Lo digo por que nos dices "y podrían haber muchas más cosas". Digamos que se compone de N "campos".

Información que se necesita acceder en tiempo de ejecución, sin depender de la instancia de la clase.

A su vez cada clase heredera de esos N campos va a sobreescribir unos M campos.
Ahora, una vez sobreescritos en base a esos N datos, mediante algún algoritmo que desconocemos, se toma la decisión de crear una de las X clases herederas.

He aquí mis dudas:
1. ¿Ese N va a ser dinámico? O después de un tiempo de análisis quedará fijado. ¿De cuanto será el valor, al menos en un estimado?
2. ¿De esos N datos, cúantos son potencialmente cambiantes en las clases herederas? ¿Se puede estimar ese M?
3. ¿Estos N datos para que se emplearán después? ¿Cálculos y operaciones dentro de la clase instanciada? ¿Le es de utilidad a la clase o sólo son empleados para tomar la decisión de cual crear?
4. ¿Las X clases descienden de esta clase base, o existe dentro de X clases, alguna cantidad Y que ramifique el árbol aún más? Es decir: Y clases descienden de una clase intermedia entre éstas y la clase base?

Y si no es molestia, ¿podríamos conocer algo más del ambiente o contexto que estamos analizando?

Saludos,

[poyo]

Empezado por Delphius

1. ¿Ese N va a ser dinámico? O después de un tiempo de análisis quedará fijado. ¿De cuanto será el valor, al menos en un estimado?

No, no va a ser dinámico. Todavía no lo definí del todo. pero en principio serían los que nombré (8) y otros 2 ó 3 más que no son necesariamente Strings. Por ejemplo hay uno de Integer que lo usaría como Bitfield (para flags)

Empezado por Delphius

2. ¿De esos N datos, cúantos son potencialmente cambiantes en las clases herederas? ¿Se puede estimar ese M?

En una primera generación de heneracia (se dice así?) serían todos.
En clases heredadas a partir de esa, por lo general son 2 ó 3, aunque no descarto 4 ó 5 (si es que cambia el autor, licencia y cosas por el estilo).

Empezado por Delphius

3. ¿Estos N datos para que se emplearán después? ¿Cálculos y operaciones dentro de la clase instanciada? ¿Le es de utilidad a la clase o sólo son empleados para tomar la decisión de cual crear?

Sólo son para tomar la decisión.... aunque pensando bien, a lo mejor, para Log el nombre/ID viene bien.

Empezado por Delphius

4. ¿Las X clases descienden de esta clase base, o existe dentro de X clases, alguna cantidad Y que ramifique el árbol aún más? Es decir: Y clases descienden de una clase intermedia entre éstas y la clase base?

Sería de múltiple ramificación. Los descendientes directos de la base los llamo de primera generación (a eso me refería arriba) y luego éstos podrían tener varias ramificaciones y esos también... aunque creo que rara vez se dé más de 4 "generaciones" (niveles o como se diga).

Empezado por Delphius

Y si no es molestia, ¿podríamos conocer algo más del ambiente o contexto que estamos analizando?

Por ahora es algo experimental, prototipo por decirlo de algún modo. Sería para testear, comprobar funcionamiento, entender mejor, mejorar, reimplementar, depurar, comparar, etc. muchos algoritmos. Bulgarmente hablando, necesito "cagarlos a palos" para ver cómo responden, si tienen bugs, qué consumo de recursos, etc, para poder tomar mejores decisiones de uso.
En principio sería para Delphi/Win32.

[[Delphius]]

Pues si sólo se van a emplear para saber que clase crear, me parece un desperdicio tener X+1 (el uno de la clase base) clases que redefinan dicho conjunto de datos.

A como lo veo una Factoría con su propio motor de estados/reglas/algoritmos de decisión sería suficiente como para saber cual de las todas las clases crear.

Esta factoría buscaría buscaría dentro de una "matriz" (abstractamente hablando) y mediante algunas reglas de decisión nos devolvería la clase adecuada, y quizás, hasta con los valores inicializados adecuados.

La clase recibiría como parámetros (o contar con propiedades/campos) los datos necesarios para moverse por la "matriz" y tomar sus propias decisiones en un método destinado a tal fin.

Por dominio o ambiente me refería al contexto del algún negocio o empresa que estás analizando. Si dices que es algo experimental, pues habría que ver.

Igualmente el tema de esta factoría habría que ver, y en esto influye el como haces para determinar que clase crear (tu algoritmo) y el mismo negocio bajo estudio.

Saludos,

[poyo]

Bueno, les comento que ya he solucionado el problema tal como lo expuse la última vez.
Al, lo que planteaste arriba, nunca lo había visto para ese lado. Es algo que lo suelo hacer bastante seguido en C (lo del array y luego para el índice uso un Enum), pero no sé porque en Delphi no se me cruzó... curioso. bien ahí! Lo voy a tratar de tener más en cuenta.
Lo bueno de estos debates es que siempre se sacan cosas positivas, no?

Empezado por Delphius

Pues si sólo se van a emplear para saber que clase crear, me parece un desperdicio tener X+1 (el uno de la clase base) clases que redefinan dicho conjunto de datos.

A como lo veo una Factoría con su propio motor de estados/reglas/algoritmos de decisión sería suficiente como para saber cual de las todas las clases crear.

Esta factoría buscaría dentro de una "matriz" (abstractamente hablando) y mediante algunas reglas de decisión nos devolvería la clase adecuada, y quizás, hasta con los valores inicializados adecuados.

La clase recibiría como parámetros (o contar con propiedades/campos) los datos necesarios para moverse por la "matriz" y tomar sus propias decisiones en un método destinado a tal fin.

No muy entiendo bien a qué te refieres... con lo de la matriz suena a lo que mi programador de confiaza (me refiero a mi amigo y socio de aventuras programacionales) 2 x 3 me sugiere de usar: automátas.

Sigo con cómo lo pienso usar: Imáginate una aplicación donde hay un Virtualtreeview funcionando como treeview/checkbox/listview (con columnas, mostrando el "resumen" de cada algoritmo + datos estadísticos + lo que sea.
El operador (yo en este caso), menú mediante, cargo desde distintas DLLs los algoritmos en lo que va a ser una sesión de trabajo.
Allí, a medida que cargo las DLL's se registran los algoritmos y se agregan al treeview acorde a la jerarquía de clases.
Una vez que tengo todo lo que quiero en el treeview, selecciono con click los que voy a quere trabajar (puede que todos, puede que 1 o más)
Una vez que tengo seleccionado los que quiero, elijo qué operación quiero hacer: distintos Benchmarcks/tests.
Con la info obtenida, más el resumen, puedo tomar decisiones acerca de qué es lo que me conviene para determinada situación. Es decir, puedo comparar tiempos, recursos consumidos, licencias, precios, o cosas que puedan ir surgiendo.

Empezado por Delphius

Por dominio o ambiente me refería al contexto del algún negocio o empresa que estás analizando. Si dices que es algo experimental, pues habría que ver.
Igualmente el tema de esta factoría habría que ver, y en esto influye el como haces para determinar que clase crear (tu algoritmo) y el mismo negocio bajo estudio.

De negocios no entiendo mucho que digamos... mmmm... no sé qué cosas perversas te inculcarán en la univeridad pero yo de chiquito aprendí a hacer lo que me gusta. jejejeje. (CHISTE, aclaro antes que oscurezca).
Pero en verdad, la única necesidad es mi sed de programar y aprender un poco más que lo que me gusta, además de hacer más amena la ardua tarea de seguir programando.