14

I have attended a job interview. The interviewer asked me why you need private variable. If you achieve something by defining a variable private, can't you achieve the same by defining any other access modifier defined in java?

According to Java Specification Languages,

A private class member or constructor is accessible only within the body of the
top level class (7.6) that encloses the declaration of the member or constructor.
It is not inherited by subclasses.

But, if i am designing a class, how can i take decision to define a variable "private"?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Shashi
  • 12,487
  • 17
  • 65
  • 111
  • I don't understand the question. Is it why you would want to declare a variable private? Is it if you could get the same effect as `private` with other access modifiers, or possibly other access modifiers with other program changes or constraints? – David Thornley Nov 29 '10 at 19:07

9 Answers9

39

By limiting the access of "other code" (perhaps written/maintained by others) you are more free to change it in the future without having to worry about breaking some other code that relies on it.

The question is not "should I make this private?", but rather "is there a need for this to be non-private?". Is there some other code that is likely to need access to the variable?

If that turns out to be the case, you assign the proper access (possibly via getters/setters) and accept that changes to it will be difficult. Else you leave it private.

Kris
  • 14,426
  • 7
  • 55
  • 65
  • 6
    "not "should I make this private?", but rather "is there a need for this to be non-private?"." My thoughts exactly. – WernerCD Nov 24 '10 at 14:39
11

I think you should look at it from the other direction: why would you make a variable anything but private? Proper encapsulation means hiding the details of your implementation so the default should be to make fields private.

GaryF
  • 23,950
  • 10
  • 60
  • 73
8

Basically, once you make a variable public, you’re committed and can never go back on this decision. Every future change would change the public interface of your class, which in turn means that every usage of that class needs to be changed. For a public API, this is unthinkable; your library effectively broke backwards compatibility.

Even for privately used classes, this is kind of a big deal.

So when would you ever change the scope of a variable to private in the future? There are many conceivable reasons for this. The easiest is that your class might need to do something every time the variable’s value is changed (e.g. log the change, or update other variables accordingly). Or you decide later on that the variable isn’t needed at all, and that the value that is requested by the user should be computed on the fly instead.

If you’re directly reading or setting a variable, that’s not possible. Instead, your class needs to force the user to call a getter/setter, by forbidding direct access to the variable and offering appropriate public getter/setter methods in its place.

Because in general you can never foresee such future changes, it has become accepted best practice to make no variable public. Every variable should be private (or at least internal).

(There’s one exception: in some cases, final variables can safely be made public. For example, enum-like constants are often implemented as public final variables in Java libraries because they will never change, and no access control is required since they are read-only anyway).

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
7

A general rule of thumb is to reduce the scope of variables and methods. The more things you keep private the more easily you can change your class with out causing problems in other parts in the system (ie: you reduce coupling).

So as a general rule private should be default

hhafez
  • 38,949
  • 39
  • 113
  • 143
3

So, you have to ask yourself why it has to be private. So, how about using the truth by contradiction idea.

Can it be public? If the answer is, you do not want people to be able to access and modify the attribute directly, then it cannot be public.

Can it be default? If the answer is, you do not want the same package to be able to access and modify the attribute directly, then it cannot be default.

Can it be protected If the answer is, you do not want subclasses to access and modify the attribute directly, then it cannot be protected.

Therefore, if all answers are No (and you have to determine the answers of why you don't want the access in those scenarios), then it must be private.

The question is asking, do you really understand what the modifiers give you, and how they can be accessed, and not to blindly make everything private, and create setters and getters, because that is what your lecturer/book/manual taught you.

Codemwnci
  • 54,176
  • 10
  • 96
  • 129
  • 1
    I would start with the assumption that its should be private, unless it has to have a wider access scope. – Peter Lawrey Nov 24 '10 at 12:30
  • for sure, private is safer. But whichever way you look at it, you should *think* about the access you are trying to give, and understand why you are or are not putting the restrictions on it. – Codemwnci Nov 24 '10 at 12:33
  • As default is more restrictive than protected I would change the order of your questions... – pgras Nov 24 '10 at 13:03
  • Is default more restrictive? I would say they are different, rather than more or less. Protected only allows extending classes to have visibility, default allows any class within your package to have visibility. So more or less depends on your viewpoint. – Codemwnci Nov 24 '10 at 13:17
  • **no**, `protected` allows classes within the package to have visibility as well. It really is `default` + subclasses, and in that respect `default` is definitively more restrictive. – Andrzej Doyle Jan 27 '11 at 13:07
3

If you achieve something by defining a variable private, can't you achieve the same by defining any other access modifier defined in java?

Yes. That's true. Any private can be changed to public (or protected and so on) and the program will compile and run just as it did before.

The access modifiers are there for the programmers convenience, and helps him properly define the interface of the class. Have a look at the wikipedia article on encapsulation.

aioobe
  • 413,195
  • 112
  • 811
  • 826
2

the member is private in the cases:

  1. it is a property, it's reading and writing should be performed only via class methods
  2. it has sense only in context of the object and nowhere else
  3. it shouldn't be visible from outside the class

The object of such design is encapsulation, which means that you has your class implementation hided from the client code. It improves readability, maintainability and testability of the code.

Vladimir Ivanov
  • 42,730
  • 18
  • 77
  • 103
1

The main point of classes is to encapsulate data and behavior and hide internal implementation, while exposing clean, simple and useful API externally.

There are two different things to consider: public contract (API) and private data.

  1. Private fields: this is your private data, which you don't want exposed externally because of: security and integrity.

  2. Private methods: your utility functions to make code more readable and maintainable.

  3. Public methods: a contract (interface, API) that you expose to the other people. That's what makes your classes useful.

  4. Public fields: don't use this. It exposes only part of your internal data. For simple classes might be ok, while for complex classes with interdependent fields this is a big no-no. For exposing functionality you should use public methods (point 3.).

Peter Knego
  • 79,991
  • 11
  • 123
  • 154
0

Many of these comments apply to inner/nested class, methods and constructors.

Basically, you want to make access as restricted as possible without creating undue complexity. If you can make something private or static, I suggest you that. If you can make a field final, this usually help improve clarity as well.

When a field or any member is private you can immediately see where it is used and when its is no longer used.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130