constantes de classes demasiado estáticas :P

[poyo]

Ayer estaba haciendo unas pruebas con las constantes de classes y la verdad, deja mucho que desear...
Me encontré con un "Internal Error" en el debugger... parece que no le sienta bien el tema bajo ciertas circunstancias.

Como conclusión llegué a que lo que quería hacer no era la manera usando constantes de Classes:

Hice una prueba con las siguientes 3 classes:

Código Delphi [-]
type
  TClass0 = class(TObject)
  public
    const A = '';
  end;

  TClass0CLass = Class of TClass0;

  TClass1 = class(TClass0)
  public
    const A = '111';
  end;

  TClass2 = class(TClass0)
  public
    const A = '222';
  end;

Luego creé un procedure que me devuelva el valor de la constante, dependiendo de la clase:

Código Delphi [-]
function GetaA(AClass: TClass0Class): string;
begin
  with AClass.Create do
  try
    result := a;
  finally
    free;
  end;
end;

y lo siguiente:

ShowMessage(GetAA(TClass0));
ShowMessage(GetAA(TClass1));
ShowMessage(GetAA(TClass2));


el "with AClass.Create do" no es necesario ya que la constante es de Clase y no necesita referencia a instancia alguna. lo hice sólo para probar.

Como verán, a mi entender, debería devolver la constante correspondiente a la Clase que se le pasa... pero no, siempre devuelve '' (vacío) Se ve que hace un cast implícito al tipo que resalté en la declaración de la función.

Les cuento la idea del uso:

Tener una clase con una seria de constantes:
TMyClass = class(TMyClassBase)
public
const Version = '1.0';
const ID = 'ID_CLASE';
const Name = 'Nombre';
const Desc = 'Descripción';
const Author = 'Author name';
...
end;

Entonces, cada vez que heredo una nueva clase, simplemente reemplazo los valores de estas constantes y listo (sólo los que necesito). Muy sencillo, pero no funcionó.
La idea era evitar escribir código, es decir, una función de clase de tipo string para cada uno de esos valores.
Estas constantes se deben ver antes de instanciar los objetos, por eso deben ser de Clase.
Otra opción a las funciones de clases serían las variables de clase, pero requieren inicialización... y estoy escribiendo código otra vez!
parece que no voy a salvarme!

alguna sugerencia o idea?

[[Delphius]]

Hola poyo, Se que las constantes de clases es un añadido en las versiones nuevas, si lo intento hacer en D6, se que me va a pegar un reto.

Desconozco como es el concepto de constante de clase, más me llama la atención de que se pretenda modificar el valor. Digo... si es que el concepto de constante se mantiene, es para mi de esperar que el valor no pueda ser sobreescrito en una clase descendiente.

A lo que voy es que si es constante... es constante.

Saludos,

[poyo]

claro, es constante pero es para esa clase... es decir, cada clase puede tener la misma constante (mismo nombre) pero cada una tiene su propio valor... a ver un ejemplo a groso modo para que se entienda:

type
TPlaneta = class(TObject)
public
const Gravedad = 0;
end;

TTierra = class(TPlaneta)
public
const Gravedad = 9.81;
end;

TJupiter = class(TPlaneta)
public
const Gravedad = 26.00;
end;

El valor es inalterable, pues es constante, pero cada clases tiene su propia constante.
Cuando me refiero ca sobreescribir el valor de la constante me refiero a crea una nueva clase con otor valor de la misma constante, como en el ejemplo. se entiende?

[[Delphius]]

¿Y eso compila?
Como he dicho, tengo D6 y desconozco el concepto.
A como yo lo interpreto no debería permitirse declarar una misma constante en clases descendientes.

Yo lo analizo con un poco de lógica conceptual.

Un Perro es un animal, y como animal éste hereda las características comunes que le son atribuidas a todo animal. Si esto es así, Perro por tanto comparte las características de un animal más la que le son propias a un perro.

Viéndolo así, definir una constante para una clase implica que cualquier clase que herede de ésta reciba y herede la misma constante.

Cuando deseamos añadir un método a una clase cuya implementación le puede o no ser propia a cada sub-clase lo definimos como virtual; si el comportamiento debe necesariamente estar en la subclase más no en la clase lo definimos además como abstracto. Esto nos permite que luego cada clase pueda sobreescribir dicho método y ampliarlo según el contexto. En el caso del perro y los animales diríamos que Corre() es posiblemente un método abstracto, como un animal corre depende de cada uno: un perro corre de forma distinta a la de un gato, muy a pesar de que ambos poseen el mismo objetivo: moverse a mayor velocidad de un punto a otro.

Volviendo a las constantes, como clase heredera, hereda el mismo valor. Hacer uso y sobreescribir una misma constante implicaría un concepto abstracto, y esto rompe con la filosofía de una constante y el concepto de la herencia.

¿Me explico?

Saludos,

[poyo]

sí, compila desde D7. si no me equivoco, las constantes de clase (al igual que variables de clase y otras cosas) se han agregado en esa versión.
Entiendo bien lo que planteas y comparto.
El tema es que, así como cada clase tiene un puntero con una constante (Classname) y todos los objetos que heredan del Tobject heredan esa característica (la de tener una constante con su propio nombre), los muchachos de delphi quisieron hacer algo parecido.
Igual, si vamos al caso... no existe "casi" nada constante en este universo... no te olvides que la ram es volátil! :P

siguiendo con las classes del último ejemplo, sigue esto a colación:

Código Delphi [-]
function Gravedad(AClass: TPlaneta): double;
begin
  result := AClass.Gravedad;
end;

procedure test;
var
  Tierra: TTierra;
begin
  Tierra := TTierra.Create;
  showmessage(floattostr((Tierra.gravedad))); // esto devuelve 9.81;
  showmessage(floattostr(Gravedad(Tierra)));  // esto devuelve 0;
  tierra.free; //que lindo suena!

end;

[[Al González]]

Hola Poyo. Como siempre un gusto.

Al menos hasta Delphi 7, el compilador no permite la declaración de constantes de clase.

Comparto la opinión de Marcelo.

Entiendo que las constantes de clase sirven para encapsular, dentro de una clase, valores fijos que pueden ser resueltos en tiempo de compilación (una manera de definir el concepto constante) y que habrán de ser utilizados principalmente por los métodos de esa clase.

Claro, para alguna rutina exterior también podrían ser útiles, pero veo que esperabas que tuvieran el mismo efecto dinámico de los métodos virtuales. No estoy seguro de que eso deba ser así, pues el comportamiento normal de un método es estático, ¿entonces por qué el comportamiento normal de una constante de clase debería ser virtual?

Creo que la solución que buscas debería hacerse con métodos clase virtuales.

Aunque claro, sería estupendo que el compilador aceptara esta forma alternativa de declarar métodos:

Código Delphi [-]
TPlaneta = class(TObject)
public
  Class Function Gravedad : Double = 0; Virtual;
end;

TTierra = class(TPlaneta)
public
  Class Function Gravedad : Double = 9.81; Override;
end;

(sin mayor implementación de los mismos).

De momento, escribir la implementación con Begin y End tampoco significa un gran esfuerzo.

Saludos.

Al González.

[[Delphius]]

Empezado por Al González

Comparto la opinión de Marcelo.

Muchas gracias Al.

Esta vez dije algo y no me llevo el tirón de orejas o una patadita bien merecido... ¡eso significa que estoy aprendiendo!

Empezado por Al González

Creo que la solución que buscas debería hacerse con métodos clase virtuales.

Yo no veo otra alternativa, según lo que tengo entendido y estudiado al momento.

Empezado por Al González

Aunque claro, sería estupendo que el compilador aceptara esta forma alternativa de declarar métodos:

Código Delphi [-]
TPlaneta = class(TObject) 
  public Class Function Gravedad : Double = 0; Virtual; 
end;  
TTierra = class(TPlaneta) 
  public Class Function Gravedad : Double = 9.81; Override; 
end;

(sin mayor implementación de los mismos).

De momento, escribir la implementación con Begin y End tampoco significa un gran esfuerzo.

Saludos.

Al González.

Yo me haría un lío. No niego que se ahorra lineas y que puede llegar a ser interesante... pero yo que estoy acostumbrado a "lo de siempre"... encontrarme con algo así me desorientaría.

Saludos,

[poyo]

sería fantástico declarar las funciones así!
lástima...

el tema es que, en principio, tengo que hacer muchísisimas clases (más de 40, en un principio) donde cada clase tiene al menos 4 métodos virtuales que tengo que escribir para devolver un simple string... :'(
La idea era ahorrarme la declaración y la implementación que involucran las funciones de Clase.
Antes de ponerme de ese modo voy a probar un poco con las variables de clase, aunque estas necestan inicialización (ya que no se les puede asignar el valor en la declaración)
Gracias por las respuestas!

[roman]

Empezado por Delphius

Desconozco como es el concepto de constante de clase, más me llama la atención de que se pretenda modificar el valor. Digo... si es que el concepto de constante se mantiene, es para mi de esperar que el valor no pueda ser sobreescrito en una clase descendiente.

Yo siempre he entendido una constante como un valor que no cambia durante la ejecución. En este sentido, lo que dice poyo se ajusta a la definición, más allá de si las clase heredadas revalúan la constante. Esto es, el cambio de valor al pasar de una clase a una descendiente, sale del ámbito de ejecución, se realiza al codificar, más no al ejecutar.

La verdad es que yo vería muy natural que las constantes de clase se comportasen como esperaba poyo. El mismo ejemplo que da con ClassName es, en mi opinión, bastante esclarecedor.

En alguna ocasión me enfrenté a algo similar, queriendo hacer una jerarquía de clases para encapsular entidades reales como TCliente, TFactura, TProducto, etc., todas ellas descendientes de una clase base TObjetoPersistente.

Para saber en qué tabla de la base se debían guardar los datos, cada clase debía inicializar una propiedad TableName en el constructor. Pero, realmente, dicha propiedad es una propiedad de la clase y no de una instancia en particular; así que se antojaba tener dichas constantes de clase.

Como comenta Al, se puede hacer uso de funciones de clase virtuales, pero no deja de mosquear el hecho de tener una función que siempre regresa el mismo valor, ¿para qué?

En fin, que no aporto nada, pero quería comentar que no se me hace extraña la necesidad del comportamiento que esperaba poyo.

// Saludos

[[Al González]]

Empezado por roman

...En fin, que no aporto nada, pero quería comentar que no se me hace extraña la necesidad del comportamiento que esperaba poyo.

Vaya, al menos a mí me hace reflexionar lo que comentas. Viéndolo como explicas, quizá no estaría mal que las constantes de clase tuvieran esa capacidad.

[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.

[[Delphius]]

Empezado por 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?



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.



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.

Ha pues, a como yo estaba interpetando lo que decías, para mi eso tenía mucho gusto y olor a una factoría.

Con matriz me refería a que por la forma en como se organizan los datos, de una forma abstracta podríamos decir que es esquema es el siguiente:

------ Campo1 - Campo2 - ... - CampoN
Clase1    X
Clase2                           X
...
ClaseM            X

Autómatas... ummm quizás. La matriz es sólo algo visual, No importa el método empleado, lo que importase es que se siguiera algunos pasos o reglas hasta llegar a la clase a crear.

Por ello yo decía una fábrica que crea un objeto de la clase elegida en función de las reglas que se van aplicando.

Así lo estaba entendiendo yo.

Ese "motor de reglas" podría tal vez eliminar unas cuantas clases intermedias. Por lo general las clases intermedias no se las emplean para ser instanciadas, sino para organizarse mejor. Es de esperar que las ramas sean las que más se instancian. En un buen diseño quizá se consiga eliminar cierta redundancia y esto podría traducirse en hasta un ahorro del 25% de las clases.

Pero ahora que describes el tema, me parece que esto de la fábrica no es ni remótamente aplicable.

Jaja... eso del negocio.. digamos que yo tampoco soy de tanto negocios. En concreto es el término que se emplea para referirse al ambiente del problema que se está analizando.
Pensaba que se trataba de algo para un cliente, pero como dices que es para ti va a ser difícil que alguien externo a tu forma de trabajar lo capte. No hay alguien que mejor que tu para comprender tu propia idea.

Saludos,