Dichiarare una finale di classe? [duplicare]

17

Mi piace che il mio codice sia scritto bene; tuttavia, ho incontrato non proprio un problema, ma più una domanda sulle convenzioni. Dì che ho questo corso.

public class Test {

    public void doStuff() {
        System.out.println("stuff");
    }
}

Questa classe non verrà estesa, quindi dovrebbe essere definitiva? So che quando non vuoi che una classe sia estesa, rendila definitiva; tuttavia, in questo caso la classe non verrà estesa. Scusa se questo è confuso. Fondamentalmente mi sto chiedendo se dovresti fare ogni classe che non sarà estesa al finale.

    
posta Jake Anderson 18.05.2015 - 01:14
fonte

2 risposte

13

Una delle regole per checkstyle con cui ho una relazione amore / odio è Class Design sezione - Progettazione per l'estensione . Spesso mi sono ritrovato a spegnerlo perché è fastidioso seguire una "T", specialmente su grandi progetti legacy in cui non viene seguito (avere un avviso di bajillion dallo stile di controllo rende più difficile correggerli).

Detto questo, è una regola piuttosto semplice:

The exact rule is that nonprivate, nonstatic methods of classes that can be subclassed must

  • be abstract or
  • be final or
  • have an empty implementation.

Se riesci a creare una sottoclasse di una classe, dovresti fare in modo che possa essere esteso in modo significativo.

"Aspetta", dici, "Questa è una regola sui metodi pubblici non statici che devono essere astratti, definitivi o con un'implementazione vuota. Che cosa ha a che fare con una classe finale?"

The exact rule is that non private, non static methods of classes that can be subclassed must ...

Se lasci una lezione non-finale, stai dicendo che può essere sottoclassificata in modo significativo. Se non può, non dovrebbe essere in grado di essere sottoclasse.

Facendo una finale di classe, stai rendendo un po 'più difficile per il tuo collega armeggiare con le sue viscere creando una sottoclasse che esponga tutti i metodi che sono specifici dell'implementazione. Ci sono alcune cose meravigliose come rintracciare un bug perché un immutabile che hai scritto è stato sottoclassato per diventare mutabile - fidati di me su questo.

La progettazione per l'ereditarietà è costosa. Ci vuole un pensiero in più per assicurarti che tu stia facendo bene. Che qualcun altro non lo rovinerà. Dicendo final class stai evitando tutto questo e dicendo "no - questo non può essere ereditato" e rendendo molto più facile ragionare.

Se sei non che spende il tempo per progettare la classe per l'estensibilità, la cosa appropriata da fare è assicurarsi che nessuno faccia l'errore lavorando dalla convinzione che la classe è estensibile.

Lettura correlata:

risposta data 18.05.2015 - 01:47
fonte
11

Eric Lippert ha un post sul blog eccellente sul perché uno segna le classi finali. Nello specifico, si riferisce alla pratica Microsoft di dichiarare le classi .NET Framework sealed , ma i principi sono gli stessi.

Per riassumere, scrivere una classe estensibile è un gioco di palla completamente diverso rispetto alla scrittura di una classe final .

  • Classi di suggellamento significa che non devi pensare alla miriade di modi in cui un consumatore potrebbe rompere la classe estendendola.

  • La scrittura di classi estendibili richiede un processo di progettazione più rigoroso. Devi progettarli per essere facilmente, chiaramente e logicamente estensibili, una considerazione di progettazione a cui non devi pensare affatto se semplicemente sigilli la classe.

  • Si perde l'incapsulamento quando si consente l'ereditarietà di una classe.

  • Il supporto di una classe estensibile è molto più coinvolto. Sì, devi supportare i molti modi in cui un consumatore potrebbe estenderlo. Se aggiorni la classe in un secondo momento, devi preoccuparti di rompere le estensioni dei consumatori.

Vedi anche
Perché le classi non sono sigillate per impostazione predefinita?

    
risposta data 18.05.2015 - 01:48
fonte

Leggi altre domande sui tag