I'm reading the Sierra & Bates book on certification. In multiple spots they state that classes can only be modified by public or default access levels. However I can compile member classes with private and protected access levels. Is it that the compiler is not enforcing the specification?
tx,
No, it's because they couldn't think of a use for a -- or a meaning to assign to a -- top-level protected or private class. You can all access levels with nested classes, however:
public class Outer {
private class Pri {}
class Pac {}
protected class Pro {}
public class Pub {}
}
Nested classes are members, and, as such, all the same access rules make sense for them as for member varialbes and methods.
A private top-level class makes no sense. Only that class could access itself. What would be the point of that?
Likewise, a protected top-level class makes no sense. If a class can only be accessed by classes that inherit from it (and classes in the same package, of course), what's the point of that class? How would you use it?
Public obviously makes sense for top-level classes.
Default (package only) access also makes sense because a package is a group of classes that collaborate closely together, so it's reasonable that those classes might want to share some class among themselves, but not expose it to the world.
That's for nested classes. It says that top-level classes can only be public or package-private (default).
If a nested class is protected, then it's available to subclasses of the outer class (not its own subclass).
But suppose that you could apply "protected" to top-level classes. What would it mean?
> Good exposition JV, but I must say I've never really
> got why you can't have a top-level protected class. I
> can think of lots of uses. All marginally useful of
> course ... It's a bit like protected & private
> derivation in C++.
Honestly, I kind of hand-waved on that one. I have a gut feel that top-level protected classes are not particularly (or maybe not at all) useful, but I'm not able to really nail down why. I think my explanation earlier is more or less on track, but definitely not complete. I'm certainly open to somebody telling my why I'm full of shiite.
I do start with the assumption that it was a deliberate design decision that had *some* reasonable (though not necessarily unassailable) logic behind it, even if I'm not able to understand or articulate that logic.
I'm going to ignore the fact that classes in the same package can access protected things in the following stream of consciousness because I want to focus on what protected would add relative to package-private.
I wonder what would be the point of making the class protected. If only subclasses could refer to the class, then that means:
* Only subclasses could refer to that class' public methods. In that case, why not just make them protected methods in a public class.
* The parent class can't be used as an abstraction, a general type.
So, what would we gain by allowing protected top-level classes.
So, you'd be able to extend the class, but you couldn't delegate to it.
(From the perspective from outside the package.)
If you were a class outside the package, it would be like it didn't exist, except in the cases when you're descended from it.
That feels weird to me. In what applications would this be useful?
> When you want to declare a type X that inherits its
> implementation or some other feature from Y but you
> don't want the rest of the application to know it's a
> Y, or to be able to cast to it, etc.
But that sounds like this to me, not derivation:
public class X {
private Y y = new Y();
}
Oh well, the less I think about C++ the better.
