studio programacion móviles example desarrollo databindingutil databinding curso aplicaciones android memory private public

programacion - Público o privado, ¿realmente importa con las variables de Android?



import databinding android (5)

Bueno, un punto importante es que definir las variables como privadas es el estándar en la programación Java. Por lo tanto, al llamar directamente a las variables en los objetos, al menos parecerá extraño para otras personas que posiblemente puedan leer su código.

Otra cosa que diría es que si no está solo, la codificación en un proyecto siempre es una buena práctica para limitar la visibilidad de los atributos que son clave en la implementación de la clase para evitar trabajos extraños en torno a otros desarrolladores.

Personalmente, no sé si esos modificadores se utilizan para fines de compilación y optimización.

Para concluir, creo que todos los codificadores Java experimentados me atrevo a utilizar este patrón en la definición de atributos.

dentro de una sola actividad, al definir los componentes que se usarán solo dentro de esa actividad, ¿cuál es la diferencia real entre las siguientes definiciones:

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

¿hay algunas convenciones "bajo el capó" que deberían pensarse (limpieza de basura, memoria, etc.) que sugerirían usar siempre lo privado sobre lo público, si la entidad en sí solo se usará dentro de la clase en la que está escrito?


El alcance de la visibilidad no tiene nada que ver con el recolector de basura o la administración de memoria

Querrá reducir el alcance de la visibilidad tanto como sea posible para que su código sea más fácil de mantener.


Los campos privados promueven la encapsulation

Es una convención generalmente aceptada para usar private menos que necesite exponer un campo o método a otras clases. Entrar en esto como un hábito le ahorrará mucho dolor a largo plazo.

Sin embargo, no hay nada intrínsecamente malo en un campo o método público. No causa diferencia para la recolección de basura.

En algunos casos, algunos tipos de acceso afectarán el rendimiento, pero probablemente sean un poco más avanzados que el tema de esta pregunta.

Uno de estos casos tiene que ver con clases internas que acceden a campos de clases externas.

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 ); } } }


Si su declaración de variable está dentro del alcance de la Actividad, normalmente actúa como lo haría una variable con alcance.

Sin embargo, es una mala práctica de programación usar variables de un método en otro método cuando no son parámetros.

Ejemplo:

Malo:

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

Esto realmente generará un error de sintaxis porque foo se declara fuera del alcance de Bar()

Bueno:

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


private y public son palabras clave de Java que tienen el propósito de diseño orientado a objetos. Le sugiero que lea sobre esto: http://docs.oracle.com/javase/tutorial/java/concepts/

Si solo va a utilizar esas variables (objetos) en su actividad, entonces le sugiero que las haga privadas.

Espero que esto ayude.

Editar:

No estoy seguro de si utilizar la palabra clave privada, pública o sin palabra clave optimizará su aplicación desde un punto de vista de memoria. Por lo que sé, creo que no, y debería usar lo que hace que su código sea más legible, intuitivo y fácil de mantener.