pubblico o privato, è veramente importante con le variabili Android

Question

all'interno di una singola attività, al momento di definire i componenti da utilizzare solo all'interno di tale attività, qual è la vera differenza tra le seguenti definizioni:

Button btnPower = null; 
//or 
private Button btnPower = null; 
//or 
public Button btnPower = null; 

public void somethingUsingTheButton(){ 
    btnPower = (Button)findViewById(R.id.btnpower_id); 
} 

sono lì un po ' Convenzioni "sotto il cofano" che dovrebbero essere pensate (pulizia dell'immondizia, memoria, ecc.) che suggerirebbero di usare sempre private su pubblico, se l'entità stessa verrà usata solo all'interno della classe in cui è scritta?

Answer 1

campi privati ​​promuovere encapsulation

Si tratta di una convenzione generalmente accettata da usare private a meno che non è necessario esporre un campo o un metodo ad altre classi. Entrare in questa abitudine ti farà risparmiare molto dolore a lungo termine.

Tuttavia, non c'è nulla di intrinsecamente sbagliato in un campo o metodo public. Non fa alcuna differenza per la garbage collection.

In alcuni casi alcuni tipi di accesso influiscono sulle prestazioni, ma sono probabilmente un po 'più avanzati rispetto all'argomento di questa domanda.

Uno di questi casi ha a che fare con le classi interne che accedono ai campi delle classi esterne.

class MyOuterClass 
{ 
    private String h = "hello"; 

    // because no access modifier is specified here 
    // the default level of "package" is used 
    String w = "world"; 

    class MyInnerClass 
    { 
     MyInnerClass() 
     { 
      // this works and is legal but the compiler creates a hidden method, 
      // those $access200() methods you sometimes see in a stack trace 
      System.out.println(h); 

      // this needs no extra method to access the parent class "w" field 
      // because "w" is accessible from any class in the package 
      // this results in cleaner code and improved performance 
      // but opens the "w" field up to accidental modification 
      System.out.println(w); 
     } 
    } 
} 

Answer 2

Se la dichiarazione della variabile si trova all'interno dell'ambito dell'attività, agisce normalmente come una variabile con ambito normalmente.

Tuttavia, è una cattiva pratica di programmazione utilizzare le variabili da un metodo in un altro metodo quando non sono parametri.

Esempio:

Bad:

void Foo() 
{ 
    int foo = 5; 
    System.out.println(Bar()); 
} 

int Bar() 
{ 
    return foo + 5; 
} 

Questo effettivamente lanciare un errore di sintassi, perché foo è dichiarato al di fuori del campo di applicazione per Bar()

Buono:

int foo; 

void Foo() 
{ 
    foo = 5; 
    System.out.println(Bar(foo)); //prints 10 
} 

int Bar(int foo) 
{ 
    return foo + 5; 
} 

Answer 3

private e public sono entrambe le parole chiave di Java che hanno lo scopo di Object Orientated Design. Vi suggerisco di leggere al riguardo: http://docs.oracle.com/javase/tutorial/java/concepts/

Se si utilizzano solo queste variabili (oggetti) nella propria attività, suggerirei di renderle private.

Spero che questo aiuti.

Edit:

non sono sicuro se si utilizza la parola chiave privata, pubblica o no ottimizzerà si app da un punto di memoria di prospettiva. Per quanto posso dire, penso che non sia così e dovresti usare ciò che rende il tuo codice più leggibile, intuitivo e manutenibile.

Answer 4

L'ambito di visibilità non ha nulla a che fare con il garbage collector o la gestione della memoria

Si vuole ridurre la portata della visibilità, per quanto possibile in modo che il codice può essere più facile da mantenere.

Answer 5

well, un punto importante è che la definizione di variabili come private è lo standard nella programmazione java. Quindi chiamare direttamente le variabili sugli oggetti sembrerà almeno strano per le altre persone che potrebbero leggere il tuo codice.

Un'altra cosa che direi è che se non sei da solo la codifica di un progetto è sempre una buona pratica per limitare la visibilità degli attributi che sono fondamentali nell'implementazione della classe per evitare strani problemi intorno al fatto che altri sviluppatori possano venire con.

Personalmente non so se questi modificatori sono utilizzati per scopi di compilazione e ottimizzazione.

per concludere come ritengo che ogni esperto di codificatori java mi stia fortemente adoperando per utilizzare questo modello nella definizione degli attributi.