Alcuni strumenti di analisi statica contrassegnano i campi non privati con
Variable '[nameHere]' must be private and have accessor methods.
Sonar presenta costantemente tali avvisi e desidera modificare tutte le variabili protette nel mio codice in privato, perché è questo? Devo ancora vedere una variabile protetta nel mio lavoro che non ha sollevato questo avviso.
I campi che sono protected non sono nascosti con sufficiente forza per molti strumenti di analisi statici come sonar, pmd o stile di controllo . I campi protected sono visibili per sottoclassi ( documenti ) e consentono alle sottoclassi di modificare lo stato della classe senza passare attraverso i metodi di accesso che possono causare problemi nei metodi della superclasse.
Quindi, ecco perché si lamenta dei campi protected . A meno che non si stia progettando specificatamente per l'estensione (che la classe dovrebbe essere sottoclassata), è probabilmente meglio usare il livello pacchetto-privato predefinito per i campi e i metodi che si desidera siano visibili ai test (o altre classi in il pacchetto).
Personalmente, non ho mai usato un campo variabile protected all'interno di una classe, anche quelli che sono sottoclassi. protected final campi occasionalmente, ma mai un campo variabile . D'altra parte, ho spesso usato il livello di default sui metodi per test e (più spesso di protected final anche se ancora non comune) /* default */ final campi.
Lo scopo dell'avviso è di farti riflettere su come stai effettivamente presentando la classe e il contratto che stai presentando agli altri per il suo uso. Se lo fai essere troppo permissivo, è troppo facile per i colleghi prendere scorciatoie e armeggiare con le viscere della classe (una volta ho visto qualcuno creare una classe interiore che ha sottoclasse un'altra classe e creare metodi pubblici per accedere ai protetti campi). Ridurre la visibilità di campi e metodi può essere un doloroso refactoring.
Inizia con le autorizzazioni più restrittive e, quando trovi la necessità reale di un progetto più permissivo, aprilo. Questo è ciò che gli strumenti di analisi statica ti stanno incoraggiando a fare.
Lo scopo delle variabili private è nascondere i dettagli di implementazione dagli utenti della classe in modo che l'implementazione possa essere modificata senza infrangere tutto il codice che la usa.
L'ereditarietà crea una seconda serie di "utenti" della tua classe - le sue sottoclassi. Lasciare le variabili di istanza protected equivale a esporle come public alle sottoclassi.
Leggi altre domande sui tag encapsulation java static-analysis warnings