Sé que hay preguntas sobre cómo llamar al método base dentro de un método anulado como esto . Pero, ¿qué pasa si un método anulado solo llama a la clase base? ¿Es esto malo / bueno? Parece extraño, ¿por qué anular un método solo para llamar a la base de todos modos?
Por ejemplo, consulte:
public class BaseClass { virtual public void Method1() { //Do stuff } } public class InheritingClass : BaseClass { override public void Method1() { base.Method1(); } } Comentarios
- No tiene ningún propósito y simplemente desordena el código, así que deshágase de él.
- @DavidArno que ' s lo que pensé también, solo asegurándome de que no había ' una razón para ello antes de hacerlo
- En un mundo ideal, la aplicación estará cubierta por pruebas unitarias, por lo que podría eliminarlo, y cuando todas las pruebas aún pasaron, ' sabría que no era ' necesario. Sin embargo, no ' t siempre vivimos en ese mundo ideal, así que era sensato preguntar 🙂
- La única razón por la que ' d dejaría el código con el aspecto anterior si hubiera más código en el método reemplazado en el pasado, y se eliminó, pero podría verse a través de versiones antiguas en el sistema de control de fuente. Dejar un artefacto en el código actual como este podría indicar al desarrollador hoy que vea el historial del archivo ' de la versión anterior del método.
Respuesta
Pero, ¿qué pasa si un método anulado solo llama a la clase base? ¿Es este un mal / buen diseño?
¿Mal diseño ? No, una implementación bastante mala. Es engañoso para el programador de mantenimiento. Cuando no veo una anulación, sé que se llama a la base. Una anulación me dice que hay algo diferente, incluso si la base también se llama allí.
Requerir una anulación para llamar a la base sin una plantilla es de mal diseño
Hilo referenciado: el contestador más popular
Mi reacción inicial a la anulación escandinava modelo es: CODING HORROR! Parece que me veo obligado a leer todo eso, y más, para asegurarme de que el «subcomportamiento» no rompa mi código y viceversa.
El Patrón de método de plantilla es una buena manera de expresar código variable dentro de un flujo de código más grande y garantizar el orden de ejecución correcto.
En mi experiencia, es tan típico que una subclase tenga que saber qué métodos declarados en base llamar y en orden. Tome un puñado de subclases todas con la misma estructura de control de cortar y pegar, agregue 5 años de mantenimiento; ahora entiendes por qué prefiero Wild Turkey de 101 pruebas.
P.D. Todo eso es una gran razón por la que critico el uso excesivo de interface s en lugar de abstract clases.
Comentarios
- El uso excesivo de interfaces en C # probablemente proviene de no querer encadenar al implementador a esa clase base abstracta específica. El uso de una interfaz permite al implementador implementar otra clase base, y no solo esa clase abstracta específica. Sin embargo, depende mucho de las circunstancias. Creo que una buena práctica es tener una interfaz
IFooy una claseFooBase, que implementa laIFoointerfaz, con llamadas a métodos abstractos para los métodos y propiedades automáticas para los accesorios. Tal vez agregue un ctor también.
Respuesta
OMI, virtual, en la clase base, tienen una implementación muy básica. Incluso si override la definición del método virtual en la clase secundaria, aún podemos llamar al virtual (con implementación básica) si bien tiene sentido y no afecta el comportamiento previsto del método overridden en la clase secundaria.
Por ejemplo, BaseCalculator hace el trabajo real. Calculator está decorando la biblioteca BaseCalculator extendiéndola.
public class BaseCalculator { public virtual T Add<T>(T number01, T number02) { return number01 + number02; } } public class Calculator: BaseCalculator { public override T Add<T>(T number01, T number02) { Console.WriteLine(number01 + " | " + number02); var result = base.Add<int>(1, 3); Console.WriteLine("Result: "+ result); return result; } } P: ¿Qué sucede si un método anulado solo llama a la clase base?
A: En su caso, tener el método de clase base como virtual, no necesitamos override hasta que queramos cambiar su comportamiento.
P: ¿Este es un diseño malo / bueno?
A: Sí, podría tener un mal diseño, ya que puede saturar el archivo de código fuente mientras agregamos anulaciones innecesarias.
P: Parece extraño, ¿por qué anular un método solo para llamar a la base de todos modos?
A: BaseCalculator hace el trabajo real . Calculator está decorando la biblioteca BaseCalculator extendiéndola.
¡Espero que ayude!