Публичной или частной, действительно ли это имеет значение для Android-переменных
внутри одного действия при определении компонентов, которые будут использоваться только внутри этого действия, какова реальная разница между следующими определениями:
Button btnPower = null;
//or
private Button btnPower = null;
//or
public Button btnPower = null;
public void somethingUsingTheButton(){
btnPower = (Button)findViewById(R.id.btnpower_id);
}
существуют ли какие-либо соглашения "под капотом", которые следует учитывать (очистка мусора, память и т.д.), которые предполагали бы всегда использовать закрытые над публикой, если сам объект будет использоваться только когда-либо внутри класса. написано в?
Ответы
Ответ 1
Частные поля рекламируют encapsulation
Это общепринятое соглашение использовать private
, если вам не нужно выставлять поле или метод другим классам. Попадая в это как привычка, вы сэкономите много боли в долгосрочной перспективе.
Однако в поле или методе public
нет ничего неправильного. Это не имеет никакого значения для сбора мусора.
В некоторых случаях некоторые типы доступа будут влиять на производительность, но они, вероятно, немного более продвинуты, чем тема этого вопроса.
Один из таких случаев связан с внутренними классами, обращающимися к внешним полям классов.
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 );
}
}
}
Ответ 2
хорошо,
одним важным моментом является то, что определение переменных как частных является стандартом в Java-программировании.
Поэтому вызов прямых переменных на объекты по крайней мере будет казаться странным для других людей, которые могут читать ваш код.
Еще одна вещь, которую я бы сказал, заключается в том, что если вы не одиночная кодировка в проекте, это всегда хорошая практика для ограничения видимости атрибутов, которые являются ключевыми для реализации класса, чтобы избежать странной работы вокруг того, что могут появиться другие разработчики с.
Я лично не знаю, используются ли эти модификаторы для компиляции и оптимизации.
поскольку я думаю, что каждый опытный java-кодер я настоятельно рекомендую использовать этот шаблон в определении атрибутов.
Ответ 3
Объем видимости не имеет ничего общего с сборщиком мусора или управлением памятью
Вы хотите как можно больше уменьшить область видимости, чтобы ваш код мог быть проще поддерживать.
Ответ 4
private
и public
являются ключевыми словами Java, которые имеют целью Object Orientated Design. Я предлагаю вам прочитать об этом: http://docs.oracle.com/javase/tutorial/java/concepts/
Если вы собираетесь использовать эти переменные (объекты) в своей деятельности, я бы предложил вам сделать эти переменные частными.
Надеюсь, это поможет.
Edit:
Я не уверен, что если использовать закрытое, общедоступное или нет ключевое слово, вы оптимизируете свое приложение с точки зрения памяти. Насколько я могу судить, я думаю, что это не так, и вы должны использовать то, что делает ваш код наиболее читаемым, интуитивным и поддерживаемым.
Ответ 5
Если объявление переменной находится внутри области действия, оно действует нормально, поскольку обычно имеет переменную с областью.
Тем не менее, плохая практика программирования использует переменные из одного метода другим методом, когда они не являются параметрами.
Пример:
Плохо:
void Foo()
{
int foo = 5;
System.out.println(Bar());
}
int Bar()
{
return foo + 5;
}
Это фактически вызовет синтаксическую ошибку, поскольку foo
объявляется вне области видимости для Bar()
Хорошо:
int foo;
void Foo()
{
foo = 5;
System.out.println(Bar(foo)); //prints 10
}
int Bar(int foo)
{
return foo + 5;
}