In Java, are there clear rules on when to use each of access modifiers, namely the default (package private), public, protected and private, while making class and interface and dealing with inheritance?
Join them; it only takes a minute:
|
|
||||
|
The official tutorial may be of some use to you.
| Class | Package | Subclass | Subclass | World
| | |(same pkg)|(diff pkg)|
————————————+———————+—————————+——————————+——————————+————————
public | + | + | + | + | +
————————————+———————+—————————+——————————+——————————+————————
protected | + | + | + | + | o
————————————+———————+—————————+——————————+——————————+————————
no modifier | + | + | + | o | o
————————————+———————+—————————+——————————+——————————+————————
private | + | o | o | o | o
+ : accessible
o : not accessible
|
|||||||||||||||||||||
|
|
(Caveat: I am not a Java programmer, I am a Perl programmer. Perl has no formal protections which is perhaps why I understand the problem so well :) ) PrivateLike you'd think, only the class in which it is declared can see it. Package PrivateCan only be seen and used by the package in which it was declared. This is the default in Java (which some see as a mistake). ProtectedPackage Private + can be seen by subclasses or package member. PublicEveryone can see it. PublishedVisible outside the code I control. (While not Java syntax, it is important for this discussion). C++ defines an additional level called "friend" and the less you know about that the better. When should you use what? The whole idea is encapsulation to hide information. As much as possible you want to hide the detail of how something is done from your users. Why? Because then you can change them later and not break anybody's code. This lets you optimize, refactor, redesign and fix bugs without worry that someone was using that code you just overhauled. So, rule of thumb is to make things only as visible as they have to be. Start with private and only add more visibility as needed. Only make public that which is absolutely necessary for the user to know, every detail you make public cramps your ability to redesign the system. If you want users to be able to customize behaviors, rather than making internals public so they can override them, it's often a better idea to shove those guts into an object and make that interface public. That way they can simply plug in a new object. For example, if you were writing a CD player and wanted the "go find info about this CD" bit customizable, rather than make those methods public you'd put all that functionality into its own object and make just your object getter/setter public. In this way being stingy about exposing your guts encourages good composition and separation of concerns Personally, I stick with just "private" and "public". Many OO languages just have that. "Protected" can be handy, but it's really a cheat. Once an interface is more than private it's outside of your control and you have to go looking in other people's code to find uses. This is where the idea of "published" comes in. Changing an interface (refactoring it) requires that you find all the code which is using it and change that, too. If the interface is private, well no problem. If it's protected you have to go find all your subclasses. If it's public you have to go find all the code which uses your code. Sometimes this is possible, for example if you're working on corporate code that's for internal use only it doesn't matter if an interface is public. You can grab all the code out of the corporate repository. But if an interface is "published", if there is code using it outside your control, then you're hosed. You must support that interface or risk breaking code. Even protected interfaces can be considered published (which is why I don't bother with protected). Many languages find the hierarchical nature of public/protected/private to be too limiting and not in line with reality. To that end there is the concept of a trait class, but that's another show. |
|||||||||||||||||||||
|
|
|||||||||
|
|
Easy rule. Start with declaring everything private. And then progress towards public as the needs arises and design warrant it. When exposing members ask yourself if you are exposing representation choices or abstraction choices. The first is something you want to avoid as it will introduce too much dependencies on the actual representation rather than on its observable behavior. As a general rule I try to avoid overriding method implementations by subclassing; it's too easy to screw up the logic. Declare abstract protected methods if you intend for it to be overridden. Also use the @Override annotation when overriding to keep things from breaking when you refactor. |
|||||
|
|
Here's a better version of the table. (Future proof with a column for modules.)
Explanations
Which modifier to choose?Access modifiers is a tool to help you to prevent accidentally breaking encapsulation(*). Ask yourself if you intend the member to be something that's internal to the class, package, class hierarchy or not internal at all, and choose access level accordingly. Examples:
|
|||||
|
|
It's actually a bit more complicated than a simple grid shows. The grid tells you whether an access is allowed, but what exactly constitutes an access? Also, access levels interact with nested classes and inheritance in complex ways. The "default" access (specified by the absence of a keyword) is also called package-private. Exception: in an interface, no modifier means public access; modifiers other than public are forbidden. Enum constants are always public. SummaryIs an access to a member with this access specifier allowed?
What access specifiers apply toLocal variables and formal parameters cannot take access specifiers. Since they are inherently inaccessible to the outside according to scoping rules, they are effectively private. For classes in the top scope, only All the access specifiers are possible on class members (constructors, methods and static member functions, nested classes). Related: Java Class Accessibility OrderThe access specifiers can be strictly ordered
meaning that Notes
Inner classesYou also have to consider nested scopes, such as inner classes. An example of the complexity is that inner classes have members, which themselves can take access modifiers. So you can have a private inner class with a public member; can the member be accessed? (See below.) The general rule is to look at scope and think recursively to see whether you can access each level. However, this is quite complicated, and for full details, consult the Java Language Specification. (Yes, there have been compiler bugs in the past.) For a taste of how these interact, consider this example. It is possible to "leak" private inner classes; this is usually a warning:
Compiler output:
Some related questions: |
|||
|
As a rule of thumb:
As a result, if we divide access right into three rights:
then we have this simple table:
|
||||
|
|
|
In very short
|
|||||
|
|
The most misunderstood access modifier in Java is
|
|||||
|
Private
Methods, Variables and Constructors that are declared private can only be accessed within the declared class itself.
Private access modifier is the most restrictive access level. Class and interfaces cannot be private. Note Variables that are declared private can be accessed outside the class if public getter methods are present in the class.
Variables, methods and constructors which are declared protected in a superclass can be accessed only by the subclasses in other package or any class within the package of the protected members' class.
Protected
The protected access modifier cannot be applied to class and interfaces. Methods, fields can be declared protected, however methods and fields in a interface cannot be declared protected. Note Protected access gives the subclass a chance to use the helper method or variable, while preventing a nonrelated class from trying to use it. PublicA class, method, constructor, interface etc declared public can be accessed from any other class. Therefore fields, methods, blocks declared inside a public class can be accessed from any class belonging to the Java Universe.
However if the public class we are trying to access is in a different package, then the public class still need to be imported. Because of class inheritance, all public methods and variables of a class are inherited by its subclasses. Default -No keyword:Default access modifier means we do not explicitly declare an access modifier for a class, field, method, etc.
A variable or method declared without any access control modifier is available to any other class in the same package. The fields in an interface are implicitly public static final and the methods in an interface are by default public. Note We cannot Override the Static fields.if you try to override it does not show any error but it doesnot work what we except. Related AnswersReferences linkshttp://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html http://www.tutorialspoint.com/java/java_access_modifiers.htm |
||||
|
|
|
Private : Limited Access to Class only Default(No Modifier) : Limited Access to Class and Package Protected: Limited Access to Class,Pacakge and Subclasses(Inside and Outside Package both) Public: Accessible to Class,Package(All),Subclasses...In short everywhere |
|||
|
|
|
The difference can be found in the links already provided but which one to use usually comes down to the "Principle of Least Knowledge". Only allow the least visibility that is needed. |
|||
|
|
|
Access Modifiers are there to restrict access at several level. Public : it is basically as simple as you can access from any class either that is in same package or not. To access if you are in same package you can access directly but if you are in other package then you can create object of class. Default : it is accessible in same package from any of the class of package. to access you can create object of class. but you can not access this variable outside of the package. Protected : you can access variables in same package as well as subclass in any other package. so basically it is default + Inherited behavior. To access protected field defined in base class you can create object of child class. Private : it can be access in same class. In non-static methods you can access directly because of this reference (also in constructors)but to access in static methods you need to create object of the class. |
|||
|
|
|
Visible to the package. the default. No modifiers are needed. Visible to the class only (private). Visible to the world (public). Visible to the package and all subclasses (protected). Variables and methods can be declared without any modifiers that is called Default examples:
Private Access Modifier - private: Methods, Variables and Constructors that are declared private can only be accessed within the declared class itself.Private access modifier is the most restrictive access level. Class and interfaces cannot be private. Variables that are declared private can be accessed outside the class if public getter methods are present in the class. Using the private modifier is the main way that an object encapsulates itself and hide data from the outside world. examples:
Public Access Modifier - public: A class, method, constructor, interface etc declared public can be accessed from any other class. Therefore fields, methods, blocks declared inside a public class can be accessed from any class belonging to the Java Universe. However if the public class we are trying to access is in a different package, then the public class still need to be imported. Because of class inheritance, all public methods and variables of a class are inherited by its subclasses. example:
Protected Access Modifier - protected: Variables, methods and constructors which are declared protected in a superclass can be accessed only by the subclasses in other package or any class within the package of the protected members' class. The protected access modifier cannot be applied to class and interfaces. Methods, fields can be declared protected, however methods and fields in a interface cannot be declared protected. Protected access gives the subclass a chance to use the helper method or variable, while preventing a nonrelated class from trying to use it.
|
|||
|
|
|
David's answer provides the meaning of each access modifier. As for when to use each, I'd suggest making public all classes and the methods of each class that are meant for external use (it's API), and everything else private. You'll develop over time a sense for when to make some classes package-private and when to declare certain methods protected for use in subclasses. |
|||
|
|
|
this page writes well about the protected & default access modifier .... Protected: Protected access modifier is the a little tricky and you can say is a superset of the default access modifier. Protected members are same as the default members as far as the access in the same package is concerned. The difference is that, the protected members are also accessible to the subclasses of the class in which the member is declared which are outside the package in which the parent class is present. But these protected members are “accessible outside the package only through inheritance“. i.e you can access a protected member of a class in its subclass present in some other package directly as if the member is present in the subclass itself. But that protected member will not be accessible in the subclass outside the package by using parent class’s reference. .... |
|||||
|
|
I just want to address a detail that is extremely commonly got wrong, including by most of the answers on this page. "Default" access (when no access modifier is present) is not always the same as package-private. It depends on what the thing is.
|
|||||
|
|
||||
|
|
|
Access Modifiers in Java. Java access modifiers are used to provide access control in java. 1. Default: Accessible to the classes in the same package only. e.g.
This access is more restricted than public and protected but less restricted than private. 2. Public Can be accessed from anywhere. (Global Access) e.g.
3. Private Accessible only inside the same class. e.g. If you try to access private members on one class in another will throw compile error. e.g.
4. Protected Accessible only to the classes in the same package and to the subclasses e.g.
|
||||
|
|
|
Public Protected Default and private are access modifiers. They are meant for encapsulation, or hiding and showing contents of the class.
Private is not accessible outside the class Default is accessible only in the package. Protected in package as well as any class which extends it. Public is open for all. Normally, member variables are defined private, but member methods are public. |
|||||
|
So let's talk about Access Control and Inheritance The following rules for inherited methods are,
|
|||
|
|
|
Note: This is just a supplement for the accepted answer. This is related to Java Access Modifiers. From Java Access Modifiers:
From Controlling Access to Members of a Class tutorials:
|
|||||||||
|
protected by Mysticial Mar 28 '13 at 2:18
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?



privatehides from other classes within the package.publicexposes to classes outside the package.protectedis a version ofpublicrestricted only to subclasses. – Museful Feb 13 '13 at 9:56protectedmakes the method also accessible from the whole package. This stupidity in Java's visiblity model breaks the goal ofprotected. – Nicolas Barbulesco Aug 21 '13 at 9:51protected. As an access modifier, all thatprotecteddoes is to expose to subclasses outside the package. – Museful Mar 14 '14 at 10:59protected- and I quote - 'is a version of public restricted only to subclasses' which is not true by your own admission since protected also allows access through the whole package (ergo, it does not restrict access to subclasses.) – luis.espinal Apr 7 '14 at 13:45protected-packagefor the rare cases where we actually needed it, leavingprotectedto be equivalent to the C++ version of protected. – luis.espinal Apr 7 '14 at 13:53