FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
constantes de classes demasiado estáticas :P
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:
Luego creé un procedure que me devuelva el valor de la constante, dependiendo de la clase: 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? |
#2
|
||||
|
||||
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, |
#3
|
|||
|
|||
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? |
#4
|
||||
|
||||
¿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, |
#5
|
|||
|
|||
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:
|
#6
|
||||
|
||||
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: (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. Última edición por Al González fecha: 04-02-2009 a las 16:39:17. |
#7
|
||||
|
||||
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! Cita:
Cita:
Saludos, |
#8
|
|||
|
|||
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! |
#9
|
||||
|
||||
Cita:
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 |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
ayuda con variables estáticas !!!!!! | david_uh | Varios | 4 | 25-07-2007 00:49:14 |
Classes | -Galadriel- | Varios | 3 | 06-06-2007 02:06:43 |
Ayudaaa Pilas estaticas | alekandro | OOP | 6 | 26-04-2006 14:04:11 |
Classes o no classes? | tramjauer | OOP | 3 | 19-08-2005 21:36:17 |
Direcciones estáticas o dinámicas | Aprendiendo | Firebird e Interbase | 1 | 02-04-2004 01:07:08 |
|