PS: Not talking about inner classes.
OK, so that other guy knows Java better than I do, but I bet he can't speak Wuhanese(a Chinese Dialect) like me.
Leon Omk wrote:
PS: Not talking about inner classes.
Why protected non-inner-class is not allowed in Java? Help!
J. Insi wrote:Here Here Take a Read
OK, so that other guy knows Java better than I do, but I bet he can't speak Wuhanese(a Chinese Dialect) like me.
Stephan van Hulst wrote:But that's not what protected means, is it? Something that is protected is something that's only visible to classes that extend the enclosing class of the protected member.
Oracle wrote:The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.
Leon Omk wrote:Thanks Alex.
In my imagination, a "protected" class should be:
1. only visible to Class which extends it
2. instantiation is allowed, but only within the Class which extends it
When I invoke: new CurrentLife().whoWasI(), I expect "A happy man! A crazy man!". So that's the "protected class" in my dream.
Alex Hurtt wrote:
So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?
But what then would happen if there was a specific method or member in the class that you wanted to have only default (package-friendly) access level? What modifier would you use on this member or method to signify that?
Sure you could add private methods since there's a specific access modifier keyword for that. You couldn't really add public methods or members because doing so would be sort of along the lines of adding a public method to a default access level class...the class access level would override the public modifier on any public methods you declared making them effectively package friendly also (it doesn't matter if you have public methods, you can't see or invoke them if you can't see or instantiate the class that owns them).
If you protect the whole class then everything is going to be inheritable by other subclasses even in other packages. You might not really want this but you'd have no way of preventing
it because there is no explicit 'default (package-friendly)' access modifier keyword.
Steve
Steve Luke wrote:
Alex Hurtt wrote:
So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?
I don't think you need to make that assumption at all. Default Accessible Classes don't make that assumption. A default accessible class with a public method and a public subclass has its public method inherited by the subclass, and thus made visible to all other classes:
Steve Luke wrote:
I don't see why Protected classes couldn't do the same thing (conceptually).
But what then would happen if there was a specific method or member in the class that you wanted to have only default (package-friendly) access level? What modifier would you use on this member or method to signify that?
The access level for the class does not affect the access level of any of its members, as seen above. The members are normally accessible according to the rules of their own access level.
Sure you could add private methods since there's a specific access modifier keyword for that. You couldn't really add public methods or members because doing so would be sort of along the lines of adding a public method to a default access level class...the class access level would override the public modifier on any public methods you declared making them effectively package friendly also (it doesn't matter if you have public methods, you can't see or invoke them if you can't see or instantiate the class that owns them).
But as the above example shows - first you can have methods with a higher visibility than their containing class - second you can have a subclass with more visibility than its parent - and finally when you have the two, then the method in the parent class has visibility as defined by its access level - not its containing class. So the access modifier of the class does not override the access modifier of the member.
If you protect the whole class then everything is going to be inheritable by other subclasses even in other packages. You might not really want this but you'd have no way of preventing
But this problem is the same with the default access level classes. They can be subclasses by public classes in the same package - which then makes them accessible from other packages.
it because there is no explicit 'default (package-friendly)' access modifier keyword.
But you don't need one. If you want it 'package private' you don't add any other modifier. Why would this change?
So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?
Now if you want to say that a 'protected' class would behave like an interface where all the declared methods were always public and you can't have any other kind then ok (except in the case of the protected class the default level would be protected)...
Steve
Greg Charles wrote:Also, declaring a class protected so that nothing could see it except a class that was extending it sounds like a chicken-and-egg problem to me. If you can't see it, how can you extend it?
Paul Clapham wrote:
Greg Charles wrote:Also, declaring a class protected so that nothing could see it except a class that was extending it sounds like a chicken-and-egg problem to me. If you can't see it, how can you extend it?
Actually it would be "nothing could see it except a class that was extending it or a class in the same package". If we write off the first part as meaningless, what is left is a package-private class. Which is a permitted modifier.
But if we attempt to assign a meaning to the first part, then there are two possibilities:
(1) Nothing outside the protected class's package can extend it -- this is equivalent to making it package-private.
(2) Anything can extend it -- this is equivalent to making it public.
So that's pretty useless. But then there's the question of what classes can refer to the type:
At this point I suspect the Java designers just said "$%^^# that, we just won't allow it!"
Alex Hurtt wrote:...I think the problem is that the question "why no protected classes?" was posed but a protected class in Java is an undefined thing...it doesn't exist and the person posing the question did not define it in terms of "why can't there be a protected class and it would work exactly like this...." So we are left to guess and hypothesize as to what exactly a 'protected class' could be. Clearly, for reasons outlined in this thread, the definition of protected as it exists today doesn't really make sense when you apply it at the class level so we are left to wonder if having a protected class would mean having to redefine the role of the protected modifier in Java? You might just as well have posed the question "Why doesn't java have Norfle-dibbits?" Well tell me exactly what a norfle-dibbit is and maybe I can tell you why they aren't in Java...
Steve Luke wrote:
Alex Hurtt wrote:...I think the problem is that the question "why no protected classes?" was posed but a protected class in Java is an undefined thing...it doesn't exist and the person posing the question did not define it in terms of "why can't there be a protected class and it would work exactly like this...." So we are left to guess and hypothesize as to what exactly a 'protected class' could be. Clearly, for reasons outlined in this thread, the definition of protected as it exists today doesn't really make sense when you apply it at the class level so we are left to wonder if having a protected class would mean having to redefine the role of the protected modifier in Java? You might just as well have posed the question "Why doesn't java have Norfle-dibbits?" Well tell me exactly what a norfle-dibbit is and maybe I can tell you why they aren't in Java...
I disagree with the fact that 'protected class' is the same as 'norfle-dibbits'. The access modifier 'protected' is well defined in the java language specifications.
Steve
Eduard del Corral wrote:You first declare a public abstract class which can be extended anywhere but never instantiated.
From within the package you extend this abstract class with a default class. Now we can instantiate inside the package.*.
And with this class duo, you get to both instantiate and inherit inside the package. Outside the package we can still inherit this class, but not instantiate. **
Which is what you'd get with a protected class (if it existed) as far as I understand it.
** One may represent hiden class elements by simply implementing them in the default extending class.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Matthew Brown wrote:And what would be the point of a private class? A class that no other class can see, and therefore can't be used for anything?
Remember you have not inherited earth from your ancestor,you only borrowed it from your descendants.
Winston Gutkowski wrote:
As for your "default" class scenario, It sounds to me very much like a "skeleton" implementation, which seems to me to be reasonably handled by the "public interface/public abstract skeleton class" pattern (viz: List/AbstractList).
But like I say, maybe it's just me being thick. Can you explain exactly where you think your scenario above might be useful?
Winston