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...
Related
How to make a member of a class to be accessible only in subclasses in any packages? Protected is not a solution since it will open the member to other non subclasses classes.
Java does not provide absolute encapsulation. Some amount of discipline is required on the part of the programmer - both the original designer and anyone that uses a published API - to abide by some rules that are outside of the language. Regarding member access, you have identified one such case. What you want is not possible in Java.
Just to put this in broader perspective, I'd point out that even private members can be accessed by other classes if a programmer is willing to go far enough to do it. Calls made via JNI do not have to respect any of the access modifiers. See, e.g., Can a native method call a private method?
Other examples of out-of-language norms include the contract for equals/hashCode, which must be met for classes to behave well with respect to collections but is not enforced at the level of the language.
I understand why you want to do this; however, Java simply does not provide that capability.
You could do abstract class with protected member, and implement it in another packages. Consider you created some lib and design extensability for certain things. Later users of your lib will implement realizations of your class and has access to protected member and in same time not able to create implementation classes in your package. In example FilterReader class, it design for extensibility, after you implement it in somewhere in your code outside java.io package that protected fields and methods will be private to other classes in your package.
What you are trying to achieve ist not possible during to acces control:
https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
You may rethink your software design, since yout problem is caused by architecture.
please be more specific in your question for getting further answer.
Solving your problem may cause sideeffects and is not in a OOD manner.
The only way to acces the private member is using an getter method with same visibilty issuses.
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.
How do I change my mistakenly c#-ish design to work with sensible access protection in java?
Here is my super class
abstract class Parent {
protected parentVariable;
protected parentMethod() {
//These methods and variables contain internal workings of my sub-classes
//to avoid repetition
// I don't want classes elsewhere in the package (that don't inherit from class) to see these.
}
}
I have sub classes that have shared internal working, which I've stuck it in the super class. It's still hidden to the other classes and usable by sub classes. Wait, no: this isn't c#, this is java.
Protected(c#) != Protected(java) ≈≈ Internal(C#).
c# protected = Access is limited to the containing class or types derived from the containing class.
java protected = Access is limited to the current package
Everything in the package can see access these. That's far too permissive for these internal workings.
How do I solve this? Do I have to bring the shared code down to the sub-classes and use "private" at the cost of code repetition? Was my use of parent classes bad design in the first place? Do I have to squirrel these inheritance trees away in new packages?
There is no access modifier that allows visibility to subclasses but not to classes of the same package.
But that's not such a big problem because classes in a given package are supposed to be "friend", cooperate, and be released all at the same time.
Even if they see some fields and methods that they shouldn't use, the other classes of the package are not part of any external API that you have no control on, and the protected methods are not accessible to the external code.
So, just document that these methods and fields shouldn't be used so that you or your coworkers don't mistakenly use them. Or put this class in its own package if you're really concerned about same-package visibility.
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 suspect the answer is no, but I want to check. If I have this structure in a Java application:
-package
-ClassA
-subpackage
-ClassB
-subsubpackage
-ClassC
I want package.subpackage.ClassB to have access to package.subpackage.subsubpackage.ClassC, but I don't want package.ClassA to have access to package.subpackage.subsubpackage.ClassC. Is there any way to enforce this?
No, the only access modifiers are:
public - global access
protected - package and subclass access
"package-private" (no modifier) - package access
private - class access only
protected and package-private doesn't recursively grant access to subpackages. In short, subpackages don't really have any relationship with their parent package except for the fact that they share the same name prefix.
Here is a Java Specification Request that (I believe) deals with this issue: http://jcp.org/en/jsr/detail?id=294
This was supposed to be implemented in the just recently released Java 7, but apparently has been forgotten.
The only way that you can get this to work is through the use of inner classes. And, honestly, if that doesn't work then maybe you should be asking, "What is so important about C that A shouldn't be able to instantiate it but B and at least one other class can?"
No, there isn't. A package name is not an hierarchical construct If we have a class
foo.bar.Application
then bar is not a child-package of foo. The package is foo.bar and there is no relation between foo and foo.bar, they are totally different packages (namespaces).
Making ClassC as an internal class for ClassB may solve your task.
No. The package hierarchy in Java has no effect on package visibility.
Things are either totally public or package-private.
There is no such thing as a "friend" package or a "parent" package here.