constantes de classes demasiado estáticas :P

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