In Java, difference between package private, public, protected, and private
在Java中，在制定class和interface并处理继承时，是否有明确规定何时使用每种访问修饰符的权限，即默认（包私有）， public ， protected和private ？
官方教程可能对您有些用处。
| Class | Package | Subclass | Subclass | World
| | |(same pkg)|(diff pkg)|
————————————+———————+—————————+——————————+——————————+————————
public | + | + | + | + | +
————————————+———————+—————————+——————————+——————————+————————
protected | + | + | + | + |
————————————+———————+—————————+——————————+——————————+————————
no modifier | + | + | + | |
————————————+———————+—————————+——————————+——————————+————————
private | + | | | |
+ : accessible
blank : 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 :) )
Private
Like you'd think, only the class in which it is declared can see it.
Package Private
Can 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).
Protected
Package Private + can be seen by subclasses or package member.
Public
Everyone can see it.
Published
Visible 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.
Here's a better version of the table. (Future proof with a column for modules.)
Explanations
A private member is only accessible within the same class as it is declared.
A member with no access modifier is only accessible within classes in the same package.
A protected member is accessible within all classes in the same package and within subclasses in other packages.
A public member is accessible to all classes (unless it resides in a module that does not export the package it is declared in).
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:
long internalCounter should probably be private since it's mutable and an implementation detail. void beforeRender() method called right before rendering and used as a hook in subclasses should be protected. void saveGame(File dst) method which is called from the GUI code should be public. (*) What is Encapsulation exactly?
链接地址: http://www.djcxy.com/p/604.html上一篇: 如何判断Bash中是否存在常规文件？