public or private, does it really matter with Android variables

Question

inside of a single activity, when defining components to be used only within that activity, what's the real difference between the following definitions:

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

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

are there some "under the hood" conventions that should be thought about (garbage cleanup, memory, etc) that would suggest to always use private over public, if the entity itself is only ever going to be used inside the class it's written in?

Answer 1

Private fields promote encapsulation

It's a generally accepted convention to use private unless you need to expose a field or method to other classes. Getting in this as a habit will save you a lot of pain in the long run.

However, there isn't anything inherently wrong with a public field or method. It causes no difference for garbage collection.

In some cases some types of access will affect performance, but they are probably a bit more advanced than the topic of this question.

One such case has to do with inner classes accessing outer class fields.

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

well, one important point is that defining variables as private is the standard in java programming. So calling directly variables on objects will at least appear strange for other people that may possibly read your code.

One other thing I'd say is that if you are not alone coding on a project is always a good practice to limit the visibility of the attributes that are key on the class implementation to avoid strange work around that other developers may come up with.

I personally don't know if those modifiers are used to compiling and optimization purpose.

to conclude as I think every experienced java coder I strongly sujest to use this pattern in the definition of attributes.

Answer 3

The scope of visibility has nothing to do with the garbage collector or memory management

You will want to reduce the scope of visibility as much as possible so your code can be easier to maintain.

Answer 4

private and public are both keywords of Java that have the purpose of Object Orientated Design. I suggest you read up about this: http://docs.oracle.com/javase/tutorial/java/concepts/

If you are only going to use those variables (objects) in your activity, then I would suggest you make those variables private.

I hope this helps.

Edit:

I'm not sure if using the private, public or no keyword will optimize you app from a memory point of perspective. As far as I can tell I think it does not and you should use what makes your code most readable, intuitive and maintainable.

Answer 5

If your variable declaration is inside the Activity's scope, it acts normally as a scoped variable normally would.

It is, however, bad programming practice to use variables from one method in another method when they're not parameters.

Example:

Bad:

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

int Bar()
{
    return foo + 5;
}

This will actually throw a syntax error because foo is declared outside of scope for Bar()

Good:

int foo;

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

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