Even if this is something I don't find often, what's the reason of the comment /* package*/ before the members?
/* package */ final void attach(Context context) {
attachBaseContext(context);
mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
}
Here is an example from AOSP line 180:
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/app/Application.java
By default, members in Java use package-level access - they can be accessed by other classes in the same package, but not by classes in other packages.
Actually using this functionality is fairly rare, since you normally want all of your variables to be private (or protected), and your methods to either be private (for self-use), protected, or public.
There is no explicit "package" modifier, so there's no easy way to know at a glance if the modifier is missing because the author forgot to include the correct one, or because they intentionally wanted the member to have package-level access.
That's why, in the somewhat rare cases when you want to use package, it's good practice to put a /* package */ comment in front of the method declaration, to clearly state that you are intentionally using this access level, rather than accidentally forgetting to specify one.
The comment itself doesn't actually do anything as far as the compiler is concerned - it just makes the code easier to understand.
As a comment, it has absolutely no effect on the compiler. It can be used, however, by humans to make it clear that a member (method or field) or class is package-private.
Related
I know this applies to many languages, and not just Java, but that is the language I'm most familiar with.
I understand what the modifiers do, and how to use them. I just want to know, why do we need them? Why can't every object be accessible, whether or not it needs to be?
The reason becomes more apparent when you have to maintain a larger project. When a method or variable is public, you have to be careful when you make changes to it, because you never know which parts of the codebase rely on its exact behavior.
But when a variable or method is private, you know that it is not used outside of the class. That means there is a lot less code you have to pay attention to when you make changes.
By making class features private and public, you clearly separate the interface to the outside world from the internals. The less you exposes to the outside world, the more freedom you have with what the internal implementation does.
When you, for example, always make variables private and accessed them through getters and setters, you can later change them from a variable to a computed value, and then even later add caching to the computation for performance reasons. When it would be a public variable, you would have to change code everywhere the variable is used. But when you expose it to the outside world through getters and setters, all other code can keep using the class as if nothing had changed.
Making fields and methods private keeps other classes from improperly depending on the specific details of how a class works. The public interface (and the best case of all, an actual interface) describes how client code should interact with a library based on the semantics of the work being done. The implementer is then free to use whatever appropriate techniques to implement that interface and can make significant behind-the-scenes changes knowing that the client code will keep working.
An everyday example is the Collections group of interfaces. Most of the time, it's not important logically for code to know what particular kind of Set is in use, just that it's a collection that supports certain operations and doesn't have duplicates. This means that a method that accepts a Set<Integer> will work with any Set, including HashSet and ImmutableSet, because the person who wrote the interface wasn't poking around in the implementation's internals.
An example where this breaks down is the unfortunate tendency of some programmers to use packages in the com.sun namespace, especially when using cryptography. Upgrading to a new version of the JRE routinely breaks this code, which would have worked fine if the programmer had used the proper javax.crypto interfaces and factory methods instead of poking around in the JVM internals.
More or less they are used to control who can access your member variables and functions. It's the broader concept of encapsulation at work in Java(http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)).
From the Oracle Docs:
Access level modifiers determine whether other classes can use a
particular field or invoke a particular method. There are two levels
of access control:
At the top level—public, or package-private (no explicit modifier).
At the member level—public, private, protected, or package-private (no
explicit modifier).
http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
As to why you should do this:
It has to do with intent of use. It would probably be best described as a design choice that helps guide usage through-out the code-base. By marking something private you are telling other developers that this field or method should not be used outside it's current purpose. It really becomes important on large projects that shuffle developers over time. It helps communicate the purpose & intended uses of classes.
To avoid other classes having direct access to internal members of the class.
This is most useful for avoiding that member variables are mutated in an uncontrolled way (e.g. without proper validation, without notifying listeners, ...).
Another reason to avoid this is that the internal implementation may change at any time but you don't want to break code that uses it.
As others have noted, the concept is called Encapsulation.
Access modifiers are there to set access levels for classes, variables, methods and constructors. This provides an individual with the chance of controlling better the privacy of the application. There are 4 access modifiers.
Modifier | Class | Package | Subclass | World
no modifier:--|----yes----|------yes--------|--------no--------|-----no----|
private:-------|----yes----|-------no--------|--------no--------|-----no----|
public:--------|----yes----|------yes--------|-------yes-------|----yes----|
protected:---|----yes----|------yes--------|-------yes-------|-----no-----|
Regarding your question, we do need and use access modifiers because we need to restrict whom can call our program and in what way.
Also, when it comes to variables if you make something public, that means that I have direct access to it. Therefore, I am allowed to do whatever I want without following your guidelines through your methods.
For example:
public int maxUsers;
public void setMaxUsers(int users) throws IllegalArgumentException{
if(users > 0 && users <= 1000){
maxUsers = users;
}else{
throw new IllegalArgumentException("The users can not be less than 0 or greater than 1000")"
}
}
Imagine your whole program being based on its maxUsers. Since, you give me the right to access that variable directly, I could do this: maxUsers = -15; and not use the setMaxUsers method, which will simply make your program behave in an abnormal way (in the best case).
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.
or
If a variable is set to protected inside a Class, it will be accessible from its sub classes defined in the same classes or different package only via Inheritance.
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
Here's a better version of the table. (Future proof with a column for modules.)
We have a getter method within a class.
Within the same JAR we want the variable to be accessible with the no-identifier access level, from the same package and subpackages.
Below the access levels from: http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
Our problem is, how do we stop someone from taking the compiled .JAR, creating a class with the same package namespace definition, and being able to access our variable through the getter?
We thought about getting rid of all getters for the specific variable, and giving the variable value to other classes with setters and constructors, when they pass a reference to themselves. Obviously, they will be final classes. This way all objects needing the variable value have their own private copy.
I'm wondering though if there is a better way?
Access control modifiers (public, private, protected) are not meant as a security tool, but as an OO design tool. They're used to implement OO patterns like encapsulation, inheritance.
Even with no getter whatsoever and a private variable, any Java developer can use reflection to access the variable.
If you want to keep something secret, don't ever put it in a variable of a program executed by anyone. Keep it on your own machines.
- Reflection seems to be the evil here, using which any variable even with private access modifier can be accessed.
- Four access controls like private, default, protected, and public are introduced in Java more as a tool to support the Core Object Oriented Concept like Inheritance, Encapsulation etc...
I get a lot of warnings in eclipse like these:
Variable 'myVariable' must be private and have accessor methods.
I think I get them because I didn't set protectedAllowed manually to true in eclipse. But why is it set to false by default? Shouldn't I use protected attributes?
Theoretically, protected attributes (variables) are an anti-pattern in object-oriented languages. If only subclasses need to access member attributes of its superclass, define the attributes themselves as private and create protected accessor methods (getter and setter). This approach applies the concept of 'information hiding'. There is an alternative solution: define protected immutable (final) member attributes.
Further readings:
Should you ever use protected member variables?
http://www.codinghorror.com/blog/2006/08/properties-vs-public-variables.html
I guess, making everything private is an anti-pattern. Often classes are used in a bunch and as a whole represent encapsulated entity placed in separate package. They do not need to hide something from each other, but this rule enforces hiding for no good reason, increasing clutter and effectively making style (as I understand it) worse. Meanwhile, we often see that every class in package is public. I guess this is much worse, but checkstyle doesn't check that.
Encapsulation exists not only on class level, put also on package, system and so on. And I think that these levels are even more important.
Allowing package access simplifies programming within a package, and reduces boilerplate code. Often times, access is only needed from within the package. Private access forces you to create a lot of nearly useless accessor methods. This actually has the effect of reducing encapsulation and information hiding because a class has to expose internal data/structure application wide instead of just package wide through public accessor methods. The default package visibility also makes testing easier because test classes live in the same package as well (in test dir/tree).
I went to this interview for a software developer position and they gave me a test with some corner-case-code situations, with usually 4 options to choose.
One of the questions had an enum declared outside the class scope, I promptly checked the "does not compile" answer and went ahead with the other questions.
It was something like:
enum Colors {BLUE,RED,GREEN}
class Test {
//other code, not really important with my question
}
This code actually compiles.
Besides the fact that an interview like this (might or) might not be useful to find out if one is a good developer, what worries me is: why would I declare an enum like this? Why I can only do this with enum?
I did some testing and found out that it is visible inside the class, but not to other classes.
Sidenote: I scored really poor :P. I got the max on the theory but near the lowest possibile on the corner-case-code situations. I don't think I'll get the job.
It's not just enums. Enums are just special kinds of classes. In general you can have multiple classes declared in one file (as long as no two of them are public).
No, without an access modifier, the enum is package-private. This means it can only be used by classes in the same package. And you can't only do this with an enum, classes can also be made package-private.
More info: http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html
Sometimes this idiom can be sensible - for example, imagine you have an UploadHandler class (or something like that) which can return a status from an upload. It seems quite feasible to me to implement this status as an enum - and since the enum (e.g. UploadStatus) clearly "belongs" to the UploadHandler class, it seems fine to declare it in the same source file. (This does assume of course that it only needs to be package-private - if it's truly public it would need to be declared in its own file, which would probably make sense if it's not an internal thing any more).
As it happens, in this case I would probably make it a static inner class to make the relationship more explicit. But declaring multiple classes in the same source file isn't always bad and can sometimes help readability by setting the expectation that this is a borderline-trivial, subsidiary class. (By the same token, I don't think classes like this should do anything particularly complex or unexpected.)
It compiles actually, on my Eclipse ! ;-)
Several classes are allowed to be in the same file. The limitation is that a public class has to be defined in a file that has the same name.
It's visibility is 'package', so it should be visible in other classes in the same package too.
What can I do with that enum?
You can do anything you want with the above limitations...
Note : although you had it wrong, you shouldn't feel too bad, because it's not really a good practice either. In our CheckStyle configuration, outer classes in the same file like this are treated as errors !!
An enum specifies a list of constant values that can be assigned to a particular type.
It can be either inside or outside of the class.
I realise that this is a very basic question, but it is one which has always bothered me. As I understand things, if you declare a field private in Java then it is not visible outside of that class. If it is protected then it is available to inherited classes and anything in the same package (correct me if either of those definitions is incorrect).
Does this mean it is not possible to declare a field that is accessible to only inherited classes and not other non-inherited classes in the same package?
I appreciate that there are ways around this, but are there instances when you would want to have this sort of behaviour?
Obviously the above question applies to methods as well as fields.
Many thanks.
See: http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html
Package > Subclasses, you can never have a field only visible by subclasses but not by classes from the same package.
Basically:
private: Accessible only by the class.
public: Accessible by any class.
protected: Accessible by the class, all inherited classes and the classes of the current package (edited).
no scope defined: Accessible by all classes of the current package.
more information here.
Yes, Java's protected access is a little bit odd in that way. I can't immediately see why it's desirable at all. Personally it doesn't bother me for fields as I don't like non-private fields anyway (other than constants) but the same is true for other members.
.NET doesn't have the concept of package/namespace access visibility at all, but it has an alternative which is assembly (think "jar file" - not exactly the same, but close). Frankly I'd like to have namespace and deployment-unit visibility options, but it seems I'm doomed to disappointment...