Подтвердить что ты не робот

Публичной или частной, действительно ли это имеет значение для Android-переменных

внутри одного действия при определении компонентов, которые будут использоваться только внутри этого действия, какова реальная разница между следующими определениями:

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

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

существуют ли какие-либо соглашения "под капотом", которые следует учитывать (очистка мусора, память и т.д.), которые предполагали бы всегда использовать закрытые над публикой, если сам объект будет использоваться только когда-либо внутри класса. написано в?

4b9b3361

Ответ 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;
}