Dovrei usare metodi astratti o virtuali?

Se assumiamo che non sia desiderabile che la classe base sia una pura classe di interfaccia, e usando i 2 esempi dal basso, qual è un approccio migliore, usando la definizione di classe di metodo astratta o virtuale?

• Il vantaggio della versione "astratta" è che probabilmente ha un aspetto più pulito e costringe la classe derivata a dare un'implementazione speranzosa significativa.

• Il vantaggio della versione "virtuale" è che può essere facilmente inserito da altri moduli e utilizzato per i test senza aggiungere un mucchio di framework sottostanti come richiede la versione astratta.

Versione astratta:

public abstract class AbstractVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Versione virtuale:

public class VirtualVersion
{
    public virtual ReturnType Method1()
    {
        return ReturnType.NotImplemented;
    }

    public virtual ReturnType Method2()
    {
        return ReturnType.NotImplemented;
    }
             .
             .
    public virtual ReturnType MethodN()
    {
        return ReturnType.NotImplemented;
    }

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Il mio voto, se consumassi le tue cose, sarebbe per i metodi astratti. Ciò corrisponde a "fallimento precoce". Al momento della dichiarazione può essere doloroso aggiungere tutti i metodi (anche se qualsiasi strumento di refactoring decente lo farà rapidamente), ma almeno so qual è il problema immediatamente e risolverlo. Preferirei piuttosto che eseguire il debug di 6 mesi e 12 modifiche successive di 12 persone per vedere perché improvvisamente stiamo ottenendo un'eccezione non implementata.

La versione virtuale è sia soggetta a bug che semanticamente errata.

Abstract sta dicendo "questo metodo non è implementato qui. È necessario implementarlo per far funzionare questa classe"

Virtual sta dicendo "Ho un'implementazione predefinita ma puoi cambiarmi se ne hai bisogno"

Se il tuo obiettivo finale è la testabilità, le interfacce sono normalmente l'opzione migliore. (questa classe fa x anziché questa classe è ax). Potrebbe essere necessario suddividere le classi in componenti più piccoli per farlo funzionare correttamente.

Questo dipende dall'uso della tua classe.

Se i metodi hanno un'implementazione “vuota” ragionevole, hai molti metodi e spesso ne ignori solo alcuni, quindi usare i virtualmetodi ha senso. Ad esempio ExpressionVisitorè implementato in questo modo.

Altrimenti, penso che dovresti usare abstractmetodi.

Idealmente, non dovresti avere metodi che non sono implementati, ma in alcuni casi questo è l'approccio migliore. Ma se decidi di farlo, tali metodi dovrebbero lanciare NotImplementedException, non restituire un valore speciale.

Suggerirei di riconsiderare di avere un'interfaccia separata definita quale implementa la classe di base, quindi seguire l'approccio astratto.

Codice di imaging come questo:

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public abstract class AbstractVersion : IVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

In questo modo risolve questi problemi:

1. Avendo tutto il codice che utilizza oggetti derivati ​​da AbstractVersion ora può essere implementato per ricevere invece l'interfaccia IVersion, Ciò significa che possono essere più facilmente testati dall'unità.

2. La versione 2 del prodotto può quindi implementare un'interfaccia IVersion2 per fornire funzionalità aggiuntive senza violare il codice dei clienti esistenti.

per esempio.

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public interface IVersion2
{
    ReturnType Method2_1();
}

public abstract class AbstractVersion : IVersion, IVersion2
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();
    public abstract ReturnType Method2_1();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Vale anche la pena leggere anche sull'inversione delle dipendenze, per evitare che questa classe contenga dipendenze codificate che impediscono test di unità efficaci.

L'iniezione di dipendenza si basa su interfacce. Ecco un breve esempio. Class Student ha una funzione chiamata CreateStudent che richiede un parametro che implementa l'interfaccia "IReporting" (con un metodo ReportAction). Dopo aver creato uno studente, chiama ReportAction sul parametro di classe concreto. Se il sistema è impostato per inviare un'e-mail dopo aver creato uno studente, inviamo una classe concreta che invia un'e-mail nella sua implementazione ReportAction, oppure potremmo inviare un'altra classe concreta che invia output a una stampante nella sua implementazione ReportAction. Ottimo per il riutilizzo del codice.