Metodo sconsigliato, non obsoleto

Question

Alcune classi java devono avere proprietà private con un getter pubblico e un setter per funzionare correttamente. Ad esempio, i bean JSF e le entità JPA ne hanno bisogno. Se non fosse per quelle librerie, ci sono probabilmente alcune proprietà che non dovrebbero avere getter e sicuramente non setter. Anche i costruttori vuoti sono spesso scoraggiati per l'uso da codice personalizzato. Per esempio

@Entity 
public class MyEntity implements Serializable { 

    @Id 
    @GeneratedValue(strategy = GenerationType.AUTO) 
    private Long id; 

    public MyEntity() {} 

    public Long getId() { 
     return this.id; 
    } 

    public void setId(Long id) { 
     this.id = id; 
    } 
} 

In questa classe il metodo setId non deve mai essere chiamato da codice manuale. Tuttavia, il metodo non è deprecato, quindi un'annotazione @Deprecated sarebbe errata.

C'è un altro modo di @deprecated di raccontare un metodo non deve essere utilizzato?

Answer 1

Le entità JPA non hanno bisogno di getter e setter pubblici. I valori vengono impostati utilizzando la reflection (almeno quando si utilizza EclipseLink o Hibernate che si sta probabilmente utilizzando).

In questo particolare esempio si potrebbe semplicemente lasciare il setter fuori, ho preso l'abitudine fuori di esso e mai avuto un problema con esso. Nota: rispettare le convenzioni di denominazione Java quando si tratta di proprietà e getter/setter. Alcune librerie/framework (erroneamente imo) dipendono da questo.

Per quanto riguarda il concetto globale della questione, sono sorpreso che non ho visto un suggerimento che include la documentazione. La documentazione ha, è e sarà probabilmente la tua migliore comunicazione per gli utenti del tuo codice.

/** 
* WARNING! DO NOT USE THIS UNLESS YOU ARE GOD! 
* This will probably break stuff unless... 
* .... 
*/ 
public void doEvilHackishThings() 
{ 
    // Stuff happens here. 
} 

Se si documenta correttamente il codice, gli sviluppatori sanno quando è probabile che si interrompano. Assicurati di non applicare il codice voodoo, ecc. Una buona documentazione descrive in dettaglio cosa fa e come lo fa. Nessuno sviluppatore sano di mente toccherà il metodo di esempio senza capire perché è malvagio.

Answer 2

Si potrebbe nascondere getter e setter utilizzando un'interfaccia che è sostenuta da quella classe concreta. Ciò incoraggerebbe anche Tell, non chiedere, perché non ci sono getter che potresti usare sull'interfaccia. L'utilizzo del costruttore può anche essere nascosto nelle fabbriche.