Perché non dovremmo usare protetto statico in Java

Question

stavo attraversando questa domanda Is there a way to override class variables in Java? Il primo commento con 36 upvotes era:

Se avete mai visto un protected static, correre.

Qualcuno può spiegare perché è un protected static disapprovato?

Answer 1

È più una questione stilistica che un problema diretto. Suggerisce di non aver adeguatamente pensato a quello che sta succedendo alla classe.

pensare a che cosa significa static:

esiste Questa variabile a livello di classe, che non esiste separatamente per ogni istanza e non ha un'esistenza indipendente nelle classi che mi estendono.

pensare a che cosa significa protected:

Questa variabile può essere visto da questa classe, classi dello stesso package e le classi che mi estendere.

I due significati non si escludono esattamente a vicenda ma è piuttosto vicino.

L'unico caso che posso vedere dove è possibile utilizzare i due insieme è se si avesse una classe astratta che è stata progettata per essere estesa e la classe di estensione potrebbe quindi modificare il comportamento utilizzando le costanti definite nell'originale. Anche in questo caso è una ragione molto debole, anche se quasi sicuramente sarebbe meglio avere le costanti come pubbliche. Ciò rende tutto più pulito e consente alle persone di subclassare una maggiore flessibilità.

Per espandere e spiegare il primo punto - provare questo codice di esempio:

public class Program { 
    public static void main (String[] args) throws java.lang.Exception { 
     System.out.println(new Test2().getTest()); 
     Test.test = "changed"; 
     System.out.println(new Test2().getTest()); 
    } 
} 

abstract class Test { 
    protected static String test = "test"; 
} 

class Test2 extends Test { 
    public String getTest() { 
     return test; 
    } 
} 

vedrete i risultati:

test 
changed 

Provate voi stessi a: https://ideone.com/KM8u8O

La classe Test2 è in grado di accedere al membro statico test da Test senza dover qualificare il nome - ma non lo fa t ereditare o ottenere la propria copia. Sta guardando la stessa identica variabile.

Answer 2

membri statiche non vengono ereditate, e membri protetti sono visibili solo a sottoclassi (e naturalmente la classe contenente), quindi un protected static ha la stessa visibilità static, suggerendo un equivoco dal codificatore.

Answer 3

Non vedo un motivo particolare per cui questo dovrebbe essere disapprovato. Ci possono sempre essere alternative per ottenere lo stesso comportamento, e dipenderà dalla reale architettura se queste alternative sono "migliori" di un metodo statico protetto o meno.Ma un esempio in cui un metodo statico protetto sarebbe ragionevole, almeno, potrebbe essere il seguente:

(a cura di dividere in pacchetti separati, per rendere l'uso di protected chiaro)

package a; 
import java.util.List; 

public abstract class BaseClass 
{ 
    public Integer compute(List<Integer> list) 
    { 
     return computeDefaultA(list)+computeDefaultB(list); 
    } 

    protected static Integer computeDefaultA(List<Integer> list) 
    { 
     return 12; 
    } 
    protected static Integer computeDefaultB(List<Integer> list) 
    { 
     return 34; 
    } 
} 

Derivato da tale :

package a.b; 

import java.util.List; 

import a.BaseClass; 

abstract class ExtendingClassA extends BaseClass 
{ 
    @Override 
    public Integer compute(List<Integer> list) 
    { 
     return computeDefaultA(list)+computeOwnB(list); 
    } 

    private static Integer computeOwnB(List<Integer> list) 
    { 
     return 56; 
    } 
} 

Un'altra classe derivata:

package a.b; 

import java.util.List; 

import a.BaseClass; 

abstract class ExtendingClassB extends BaseClass 
{ 
    @Override 
    public Integer compute(List<Integer> list) 
    { 
     return computeOwnA(list)+computeDefaultB(list); 
    } 

    private static Integer computeOwnA(List<Integer> list) 
    { 
     return 78; 
    } 
} 

Il modificatore protected static può certamente essere giustificato qui:

• I metodi possono essere static, perché non dipendono da variabili di istanza. Non sono pensati per essere usati direttamente come metodo polimorfico, ma piuttosto come metodi "di utilità" che offrono le implementazioni predefinite che fanno parte di un calcolo più complesso e servono come "elementi costitutivi" dell'attuazione reale.
• I metodi non devono essere public, perché sono un dettaglio di implementazione. E non possono essere private perché dovrebbero essere chiamati dalle classi di estensione. Inoltre non possono avere visibilità "predefinita", perché quindi non saranno accessibili per le classi di estensione in altri pacchetti.

(EDIT: Si potrebbe supporre che il commento originale di cui solo per campi, e non a metodi - allora, tuttavia, era troppo generale)

Answer 4

protetta viene usata in modo che possa essere usato in sottoclassi Non vi è alcuna logica nel definire una statica protetta quando si utilizza nel contesto di classi concrete poiché è possibile accedere alla stessa variabile in modo statico. Tuttavia, il compilatore fornirà un avvertimento per accedere alla variabile statica di super classe in modo statico.

Answer 5

È malvisto perché è contraddittorio.

Fare una variabile protected implica verrà utilizzato all'interno del pacchetto o sarà ereditato entro una sottoclasse.

Rendere la variabile static lo rende un membro della classe, eliminando le intenzioni di ereditarlo. Questo lascia solo l'intenzione di essere utilizzato all'interno di un pacchetto, e per questo abbiamo package-private (nessun modificatore).

L'unica situazione che ho trovato utile è se si dichiarava una classe da utilizzare per avviare l'applicazione (come Java23X Application#launch e si desiderava essere in grado di avviarsi da una sottoclasse. il metodo è anche final per non consentire hiding. Ma questo non è "la norma", e fu probabilmente implementato per evitare che l'aggiunta di una maggiore complessità con l'aggiunta di un nuovo modo di lanciare le applicazioni.

per visualizzare i livelli di accesso di ogni modificatore, vedi this: The Java Tutorials - Controlling Access to Members of a Class

Answer 6

In realtà non c'è niente di fondamentalmente sbagliato con protected static .Se si desidera realmente una variabile statica o un metodo visibile per il pacchetto e tutte le sottoclassi della classe dichiarante, andare avanti e renderlo protected static.

Alcune persone generalmente evitano di utilizzare protected per vari motivi e alcune persone pensano non definitive static variabili dovrebbe essere evitato a tutti i costi (io personalmente solidale con quest'ultimo in una certa misura), quindi credo che la combinazione di protected e static deve guardare male^2 a quelli che appartengono a entrambi i gruppi.

Answer 7

Non c'è niente di sbagliato nell'avere protected static. Una cosa che molte persone trascurano è che potresti voler scrivere casi di test per metodi statici che non vuoi esporre in circostanze normali. Ho notato che questo è particolarmente utile per scrivere test per il metodo statico nelle classi di utilità.