• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

private and protected class - why not?

 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why protected class is not allowed in Java (and default (no access modifier) is allowed)?

Why private class is not allowed in Java (final keyword is allowed, private constructor is allowed - these two make a class not useful for other classes)?

Thanks.

PS: Not talking about inner classes.
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both are permitted, but only as inner or nested classes.

If you have a private inner or nested class, then access is restricted to the scope of that outer class. If you have a private class on its own as a top-level class, then you can't get access to it from anywhere.

If you have a protected inner or nested class, then access is permitted from inside the same package or subclasses of the outer class or something similar. If you have a protected top-level class there isn't an outer class to have subclasses to gain access from, so protected is meaningless.

Making a class final and giving it a private constructor mean that you have to work out some other way of giving access, maybe via public static methods, or a public static getInstance() method.
The final bit really means you are not allowed to extend the class. It is not usually possible to extend a top-level class with only private constructors.
 
Leon Omk
Ranch Hand
Posts: 75
Chrome Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
PS: Not talking about inner classes.


Why protected non-inner-class is not allowed in Java? Help!
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tell us which class it is "protected" to.
 
Matthew Brown
Bartender
Posts: 4566
8
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Alex Hurtt
Ranch Hand
Posts: 98
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Leon Omk wrote:
PS: Not talking about inner classes.


Why protected non-inner-class is not allowed in Java? Help!


Maybe if you can explain to us what you are trying to do and why you perceive the absence of protected non-inner classes in java to be a problem for you we can help you clear up your misconceptions. The fact that you think there need to be such classes probably is indicative of some fundamental misunderstanding which needs to be put right. You likely have some desired outcome in mind that you are trying to accomplish but are thinking about the problem in the wrong terms or something. But we can't know how to help unless you explain to us what you are trying to do.
 
J. Insi
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
he3.
wish this source is easy to understand for you
Here Here Take a Read
 
Paul Clapham
Sheriff
Posts: 20983
31
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J. Insi wrote:Here Here Take a Read


Actually... don't bother with that link. Two reasons:

  • It doesn't address the original question at all
  • Worse than that, it doesn't even give the correct definition for "protected"


  • So no, don't bother.
     
    Leon Omk
    Ranch Hand
    Posts: 75
    Chrome Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Stephan van Hulst
    Bartender
    Pie
    Posts: 5599
    55
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    So how can a top level class be protected? It doesn't have an enclosing class, does it?

    Private top level classes aren't allowed because they are useless. Protected top level classes aren't allowed because protected simply can't be applied to them by the definition of protected.
     
    Paul Clapham
    Sheriff
    Posts: 20983
    31
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.


    I don't think that's quite correct. Quoting from Oracle's tutorial Controlling Access to Members of a Class:

    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.


    People tend to forget the first part of that specification, and that's what makes this question not totally trivial.
     
    Alex Hurtt
    Ranch Hand
    Posts: 98
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.


    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.

    There is a new feature in Java 7 which may help achieve an effect something like what you are thinking of called super packages.
     
    Steve Luke
    Bartender
    Posts: 4181
    21
    IntelliJ IDE Java Python
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:


    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?
     
    Alex Hurtt
    Ranch Hand
    Posts: 98
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:


    I'm not making that assumption, I'm asking a question to try and understand how Leon imagines that the notion of a 'protected class' would work. But anyway, a default accessible class with a public method is only sub-classable in the same package is the problem. If you want to subclass the class in any other package it has to be a public class, no?

    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?




    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)...but I'm assuming (and remember this is all hypothetical since there is currently no such thing as a 'protected' top level class) you might still want to have some private, some default, and some public methods thrown in there. Or maybe the original intent the author of the post had in mind was to redefine the actual meaning of 'protected.' Idunno.
     
    Steve Luke
    Bartender
    Posts: 4181
    21
    IntelliJ IDE Java Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The original question is: Why can a class be either publicly accessible or package private? Why can't it be, for example, protected? When the question is asked, it is about the access to the class, and I don't think there is any reason that question has to be associated with re-defining what member accessibility means (after all you don't need to re-define member accessibility between public classes and dafault accessible classes). So I guess when you ask this:
    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?

    The answer for me would be: No, I don't imagine that at all.

    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)...

    I don't want to say that.

    If you are wondering what I would mean by a protected class it would be one that is accessible to other classes in the same package and any class which sub-classes it.
    I don't think I see a reason to have protected classes - but I also don't see why not (other than by definition). My one concern would be: Any class which sub-classes a protected class would mean classes in a different package would need access for purposes of sub-classing it, so there could be a 'chicken-or-the-egg' happening here - you can only sub-class classes you have access to, and you would only have access to the protected class if you sub-classed it. Is this sort of circular dependency solvable? Maybe that is why there are no protected classes... dunno.
     
    Greg Charles
    Sheriff
    Posts: 2985
    12
    Firefox Browser IntelliJ IDE Java Mac Ruby
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Leon, what you're trying to do is possible with a public base class with protected constructors. You could even declare the base class abstract as a way of showing it can't be instantiated directly, but that's not technically necessary. Other classes could see the base class, but they couldn't actually do anything with it except through one of the subclasses. Only classes that extended the base class could actually cause it to be instantiated.

    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
    Sheriff
    Posts: 20983
    31
    Eclipse IDE Firefox Browser MySQL Database
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 98
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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!"


    I think this sums it up. 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
    Bartender
    Posts: 4181
    21
    IntelliJ IDE Java Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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. I think Paul's post clears up just why the concept is not useful - to effectively apply the term to a top level class you have to define how extending a protected class works - and any such clarification just makes it the same as either the 'package-private' or public classes.

    My only counter point would be such an edge case it probably isn't worth mentioning:
    The only theoretical case I can come up with where a substitute of public or default access (with proper member access control) wouldn't suffice would be where you wanted to explicitly prevent referring to an Object by the protected classes type. For example you want to make this illegal:

    But you still want to be able to have any class extend it. Again, not sure why you would want this... just saying...
     
    Alex Hurtt
    Ranch Hand
    Posts: 98
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.


    Only as it applies to inner classes and member variables/methods. It is undefined as to how it would apply to top level classes and the person posing the question didn't really clarify how he imagined it would work...So in that respect, the notion of a protected top level class in Java is like a norfle-dibbit in that I don't know why it isn't there because I don't know what it is and there is nothing currently in existence I know of anywhere called a 'norfle-dibbit'. That is why I supposed that for protected to be applied to a top level class would require a redefinition of what 'protected' means in Java because it doesn't make much sense to have a protected top level class in Java with protected having its current definition and applicability. So a protected top level class is the same as a norfle-dibbit to me...undefined.
     
    Steve Luke
    Bartender
    Posts: 4181
    21
    IntelliJ IDE Java Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I guess we are getting into semantics here. The access modifier 'protected' is defined, and is stated as not applicable to a top level class. And the question is 'why is it not applicable?' I think this is very different than asking about a nonsensical jumble of letters. Perhaps you feel differently.
     
    Eduard del Corral
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    First off, hello everyone. I'm a newcomer and stumbled upon this thread in an attempt at grasping the core concepts of the Java language.

    Second I'm aware this discussion was abandoned but I found it a very interesting topic.

    Finally I know were talking about Santa's sled speed limit since protected outer classes don't exist; that said, I have a theory of what a protected outer class functionality might be like, and how it's currently attained:


    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.




    * Yes you can inherit your default class within the package, but that's besides the point, we're considering the abstract and default class duo to work as one protected class.

    ** One may represent hiden class elements by simply implementing them in the default extending class.
     
    Campbell Ritchie
    Sheriff
    Posts: 48652
    56
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Welcome to the Ranch
    Agree that scenario would work. It is different from protected access, however; you cannot extend the package‑private (=default access) class outside its package.
     
    Winston Gutkowski
    Bartender
    Pie
    Posts: 10273
    60
    Eclipse IDE Hibernate Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    I'm afraid I don't quite follow your logic (but maybe it's just me being thick). Assuming we're talking about a client outside the package, in order to "see" something that's protected, you must extend its container. In the case of a protected class, there is no such container unless it's nested (or inner).

    ** One may represent hiden class elements by simply implementing them in the default extending class.

    One may also represent "hidden" class elements by making them private and providing protected methods to access them (or indeed, making them protected; but I wouldn't recommend it).

    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
     
    Tushar Bhaware
    Ranch Hand
    Posts: 62
    Chrome Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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?

    This clearly explains why there is no private class. Thanks
     
    Eduard del Corral
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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



    Yes, I imagine them working as skeletons outside the package and standard default classes inside.

    The one reason I can see for them is building a suite of functions, say an image processing package, and hiding some of the package specific elements (mostly any interplay with the package API). So that these functions work well as a package but also offer the alternative of inheriting say a really complex algorithm for which ever purposes the programmer may have in mind. This would probably make more sense if the package was somehow precompiled yet still extendable (which doesn't really apply to Java).

    To be honest since this can already be achieved it's kind of like while and for loops, in that whiles can do anything a for can. However, I wouldn't know if this type of class would make this clearer or actually introduce ambiguity. Which is why I suppose it doesn't exist (redundant, could lead to bad programming habits).


    Anyway, thanks for your reply!

    PS Was actually learning this topic and after a few days of thinking about it came up with said answer. My instructor also considers it irrelevant, but in any case its a fun mental exercise and sometimes you do stumble into interesting things this way.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic