Le classi / i metodi astratti sono obsoleti?

Ho usato per creare molte classi / metodi astratti. Quindi ho iniziato a utilizzare le interfacce.

Ora non sono sicuro che le interfacce non rendano obsolete le classi astratte.

Hai bisogno di una lezione completamente astratta? Crea invece un'interfaccia. Hai bisogno di una classe astratta con qualche implementazione? Crea un'interfaccia, crea una classe. Eredita la classe, implementa l'interfaccia. Un ulteriore vantaggio è che alcune classi potrebbero non aver bisogno della classe genitore, ma implementeranno semplicemente l'interfaccia.

Quindi, le classi / i metodi astratti sono obsoleti?

No.

Le interfacce non possono fornire un'implementazione predefinita, classi astratte e metodi possono. Ciò è particolarmente utile per evitare la duplicazione del codice in molti casi.

Questo è anche un modo davvero carino per ridurre l'accoppiamento sequenziale. Senza metodi / classi astratti, non è possibile implementare il modello di metodo del modello. Ti suggerisco di guardare questo articolo di Wikipedia: http://it.wikipedia.org/wiki/Template_method_pattern

Esiste un metodo astratto in modo che tu possa chiamarlo dalla tua classe base ma implementarlo in una classe derivata. Quindi la tua classe base sa:

public void DoTask()
{
    doSetup();
    DoWork();
    doCleanup();
}

protected abstract void DoWork();

È un modo ragionevolmente piacevole per implementare un buco nel modello centrale senza che la classe derivata sia a conoscenza delle attività di installazione e pulizia. Senza metodi astratti, dovresti fare affidamento sulla classe derivata che implementa DoTaske ricorda di chiamare base.DoSetup()e base.DoCleanup()sempre.

modificare

Inoltre, grazie a deadalnix per la pubblicazione di un link al modello Metodo Pattern , che è quello che ho descritto sopra senza conoscere effettivamente il nome. :)

No, non sono obsoleti.

In effetti, esiste una differenza oscura ma fondamentale tra classi / metodi astratti e interfacce.

se l'insieme di classi in cui una di queste deve essere utilizzata ha un comportamento comune che condividono (classi correlate, intendo), allora scegli Classi / metodi astratti.

Esempio: impiegato, funzionario, direttore - tutte queste classi hanno CalculateSalary () in comune, usano classi base astratte. CalculateSalary () può essere implementato diversamente ma ci sono alcune cose come GetAttendance () per esempio che ha una definizione comune nella classe base.

Se le tue classi non hanno nulla in comune (classi non correlate, nel contesto scelto) tra loro ma ha un'azione che è molto diversa nell'implementazione, allora scegli Interfaccia.

Esempio: mucca, panchina, auto, classi non correlate al telesope ma Isortable può essere lì per ordinarle in un array.

Questa differenza viene generalmente ignorata quando affrontata da una prospettiva polimorfica. Ma personalmente sento che ci sono situazioni in cui l'una è adatta all'altra per il motivo spiegato sopra.

Oltre alle altre buone risposte, esiste una differenza fondamentale tra interfacce e classi astratte che nessuno ha menzionato in modo specifico, vale a dire che le interfacce sono molto meno affidabili e quindi impongono un onere di prova molto maggiore rispetto alle classi astratte. Ad esempio, considera questo codice C #:

public abstract class Frobber
{
    private Frobber() {}
    public abstract void Frob(Frotz frotz);
    private class GreenFrobber : Frobber
    { ... }
    private class RedFrobber : Frobber
    { ... }
    public static Frobber GetFrobber(bool b) { ... } // return a green or red frobber
}

public sealed class Frotz
{
    public void Frobbit(Frobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

Sono sicuro che ci sono solo due percorsi di codice che devo testare. L'autore di Frobbit può fare affidamento sul fatto che il frobber è rosso o verde.

Se invece diciamo:

public interface IFrobber
{
    void Frob(Frotz frotz);
}
public class GreenFrobber : IFrobber
{ ... }
public class RedFrobber : Frobber
{ ... }

public sealed class Frotz
{
    public void Frobbit(IFrobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

Ora non so assolutamente nulla degli effetti di quella chiamata a Frob lì. Devo essere sicuro che tutto il codice di Frobbit sia solido contro ogni possibile implementazione di IFrobber , anche implementazioni di persone che sono incompetenti (cattive) o attivamente ostili a me o ai miei utenti (molto peggio).

Le classi astratte ti consentono di evitare tutti questi problemi; usali!

Lo dici tu stesso:

Hai bisogno di una classe astratta con qualche implementazione? Crea un'interfaccia, crea una classe. Eredita la classe, implementa l'interfaccia

sembra molto lavoro rispetto a "ereditare la classe astratta". Puoi lavorare da solo avvicinandoti al codice da una visione "purista", ma trovo che ho già abbastanza da fare senza cercare di aggiungere al mio carico di lavoro senza alcun vantaggio pratico.

Come ho commentato sul post di @deadnix: le implementazioni parziali sono un anti-modello, nonostante il fatto che il modello di modello le formalizzi.

Una soluzione pulita per questo esempio di Wikipedia del modello di modello :

interface Game {
    void initialize(int playersCount);
    void makePlay(int player);
    boolean done();
    void finished();
    void printWinner();
}
class GameRunner {
    public void playOneGame(int playersCount, Game game) {
        game.initialize(playersCount);
        int j = 0;
        for (int i = 0; !game.finished(); i++)
             game.makePlay(i % playersCount);
        game.printWinner();
    }
} 
class Monopoly implements Game {
     //... implementation
}

Questa soluzione è migliore, perché utilizza la composizione anziché l'eredità . Il modello di modello introduce una dipendenza tra l'implementazione delle regole del monopolio e l'implementazione delle modalità di esecuzione dei giochi. Tuttavia, si tratta di due responsabilità completamente diverse e non c'è motivo di accoppiarle.

No. Anche la tua alternativa proposta include l'uso di classi astratte. Inoltre, poiché non hai specificato la lingua, vado avanti e dirò che il codice generico è l'opzione migliore dell'eredità fragile comunque. Le classi astratte presentano vantaggi significativi rispetto alle interfacce.

Le classi astratte non sono interfacce. Sono classi che non possono essere istanziate.

Hai bisogno di una lezione completamente astratta? Crea invece un'interfaccia. Hai bisogno di una classe astratta con qualche implementazione? Crea un'interfaccia, crea una classe. Eredita la classe, implementa l'interfaccia. Un ulteriore vantaggio è che alcune classi potrebbero non aver bisogno della classe genitore, ma implementeranno semplicemente l'interfaccia.

Ma poi avresti una classe inutile non astratta. Sono necessari metodi astratti per riempire il foro di funzionalità nella classe base.

Ad esempio, data questa classe

public abstract class Frobber {
    public abstract void Frob();

    public abstract boolean IsFrobbingNeeded { get; }

    public void FrobUntilFinished() {
        while (IsFrobbingNeeded) {
            Frob();
        }
    }
}

Come implementereste questa funzionalità di base in una classe che non ha né Frob()né IsFrobbingNeeded?

Sono un creatore di servlet framework in cui le classi astratte svolgono un ruolo essenziale. Direi di più, ho bisogno di metodi semi astratti, quando un metodo deve essere ignorato nel 50% dei casi e vorrei vedere l'avvertimento del compilatore su quel metodo non era ignorato. Risolvo il problema aggiungendo annotazioni. Tornando alla tua domanda, ci sono due diversi casi d'uso di classi e interfacce astratte, e finora nessuno è obsoleto.

Non penso che siano obsoleti dalle interfacce, ma potrebbero essere obsoleti dal modello di strategia.

L'uso principale di una classe astratta è di rimandare una parte dell'implementazione; per dire "questa parte dell'implementazione della classe può essere diversa".

Sfortunatamente, una classe astratta costringe il cliente a farlo tramite eredità . Considerando che il modello di strategia ti permetterà di ottenere lo stesso risultato senza alcuna eredità. Il client può creare istanze della tua classe piuttosto che definirne sempre la propria e l '"implementazione" (comportamento) della classe può variare in modo dinamico. Il modello di strategia ha l'ulteriore vantaggio che il comportamento può essere modificato in fase di esecuzione, non solo in fase di progettazione, e ha anche un accoppiamento significativamente più debole tra i tipi coinvolti.

In genere ho affrontato problemi di manutenzione molto, molto più associati alle interfacce pure rispetto agli ABC, anche agli ABC usati con ereditarietà multipla. YMMV - non so, forse il nostro team li ha usati in modo inadeguato.

Detto questo, se usiamo un'analogia del mondo reale, quanto è utile per le interfacce pure completamente prive di funzionalità e stato? Se uso USB come esempio, questa è un'interfaccia ragionevolmente stabile (penso che ora siamo su USB 3.2, ma ha anche mantenuto la compatibilità con le versioni precedenti).

Eppure non è un'interfaccia senza stato. Non è privo di funzionalità. È più simile a una classe base astratta che a un'interfaccia pura. In realtà è più vicino a una classe concreta con requisiti funzionali e di stato molto specifici, con l'unica astrazione che è quella che si inserisce nella porta come unica parte sostituibile.

Altrimenti sarebbe solo un "buco" nel tuo computer con un fattore di forma standardizzato e requisiti funzionali molto più ampi che non farebbero nulla da solo fino a quando ogni produttore non si inventasse il proprio hardware per fare quel buco fare qualcosa, a quel punto diventa uno standard molto più debole e nient'altro che un "buco" e una specifica di cosa dovrebbe fare, ma nessuna disposizione centrale per come farlo. Nel frattempo potremmo finire con 200 modi diversi di farlo dopo che tutti i produttori di hardware hanno cercato di escogitare i propri modi per collegare funzionalità e affermare quel "buco".

E a quel punto potremmo avere alcuni produttori che presentano problemi diversi rispetto ad altri. Se avessimo bisogno di aggiornare le specifiche, potremmo avere 200 diverse implementazioni di porte USB concrete con modi totalmente diversi di affrontare le specifiche che devono essere aggiornate e testate. Alcuni produttori potrebbero sviluppare implementazioni standard di fatto che condividono tra loro (la tua classe di base analogica che implementa tale interfaccia), ma non tutti. Alcune versioni potrebbero essere più lente di altre. Alcuni potrebbero avere un rendimento migliore ma una latenza peggiore o viceversa. Alcuni potrebbero utilizzare più energia della batteria rispetto ad altri. Alcuni potrebbero sfaldarsi e non funzionare con tutto l'hardware che dovrebbe funzionare con le porte USB. Alcuni potrebbero richiedere che un reattore nucleare sia collegato per funzionare, che tende a provocare avvelenamenti da radiazioni.

Ed è quello che ho trovato, personalmente, con interfacce pure. Potrebbero esserci alcuni casi in cui hanno senso, come solo modellare il fattore di forma di una scheda madre rispetto a un case della CPU. Le analogie dei fattori di forma sono, in effetti, praticamente apolidi e prive di funzionalità, come nel caso del "buco" analogico. Ma spesso considero un enorme errore per i team ritenerlo in qualche modo superiore in tutti i casi, nemmeno vicino.

Al contrario, penso che molti più casi sarebbero risolti meglio dagli ABC che dalle interfacce se queste fossero le due scelte a meno che il tuo team non sia così gigantesco che in realtà è desiderabile avere l'equivalente sopra equivalente di 200 implementazioni USB concorrenti piuttosto che uno standard centrale per mantenere. In un ex team in cui mi trovavo, in realtà ho dovuto lottare duramente solo per allentare lo standard di codifica per consentire ABC e eredità multipla, e principalmente in risposta a questi problemi di manutenzione descritti sopra.