¡Hola!
Cita:
Empezado por gushynet
Como alternativa al método que se ha propuesto he optado por captar la excepcion EAbstractError. Lo que no se es que solucion es mas eficiente:
usar MethodAddress o detectar que el objeto no tiene implementado el metodo a traves de la excepcion EAbstractError.
|
MethodAddress no te servirá pues devuelve una dirección única por cada método
registrado, sea abstracto o no (
http://www.clubdelphi.com/foros/show...94&postcount=3). Sin hablar ya del aumento de tamaño del ejecutable en caso de usar la directiva $MethodInfo.
Atrapar la excepción es una forma de lograrlo, pero tiene varios inconvenientes:
1. Te ves obligado a llamar al método. Es decir, sólo intentando la llamada podrás saber si el método es abstracto o no. Por lo que se reduce la capacidad de maniobra.
2. Dependiendo de las rutinas que el método llame directa o indirectamente, la excepción no será del todo segura para saber si el método es abstracto (el método puede no serlo, pero ¿qué tal si internamente llama a uno que sí?).
3. Puede verse afectado el rendimiento de la aplicación, dependiendo de qué tan frecuentemente se realicen llamadas a los métodos abstractos que se quiere controlar.
En mi opinión, son más eficientes las dos primeras soluciones de las tres que propuse anteriormente. E incluso la tercera (la de la instancia
dummy) podría en algunos casos resultar mejor que el manejo de la excepción.
Cita:
Empezado por gushynet
Lo que no se es si usando la excepcion me dejo algun caso por el camino, por ejemplo, que en la clase padre el metodo sea virtual y en la clase hija no se implementa porque usa el metodo virtual del padre.
|
Un método deja de ser abstracto para la clase que lo redefine y también para todas las descendientes de ésta. Sin importar que alguna de esas clases descendientes no lo redefina también.
¡Hasta luego!
Al González.
