• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

reasoning behind issues with protected fields in other packages

 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I understand that if you are in a subclass that extends a class in a different package you are not able to reference the protected variables of the base class by using an instance of the base class from within the subclass.
My question is what it the architecutal purpose behind this? Why not allow the subclass in a different package act ( in regards to protected fields of the base class ) like a protected(or even default/friendly class ) does when the subclass is in the same pacakage as the base class? This might go beyond the scope of certification study, but I'm curious of the design considerations of why this is the case.
Thanks so much for any insight into this.
Rick
-- for those just learning and want to know what I'm talking about consider the code below --
 
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I can say that in practice, you wouldn't do what you are doing.
There are two basic ways to extend functionality, either by inheritance, or by delegation. You are trying to do both at the same time by having a subclass trying to use a delegate of its parent type.
This is just bad design. If you were purely using inheritance, then the protected variable issue wouldn't come up. If you were using delegation, then it would be an issue if the enclosing class is in another package. The solution is either make the field public, add an accessor method for the field, or move the enclosing class to the same package.
I know this doesn't answer your question, but the "reason" it doesn't work the way you want it to might be because the way you want it to is seldom used.

Rob
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The AWT package is a good illustration of the answer you're looking for. Some of the components themselves are intended for extensibility, but the behavior that components use to interact isn't.
In most cases, different AWT classes (like Component subclasses and Container, a Component subclass of a different order) use field accesses because a) the classes are 'known' to each other and b) it didn't make sense to fully encapsulate those classes from each other, since they'd be used together all the time.
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JLS says that in a different package only code that is responsible for a protected member is able to accesss to it.
a.varProtected is a member in the instance a, thus only a could access to it outside the a declaring package. However the access is tried in an instance of Dog.
The Dog instance is able to access its member varProtected.
It seems that protected members, outside the package, can be accesed from its own objects, but not for the rest of the world.
Have a look at the API for the ClassLoader class. Many of the members are protected. You are not able to access them in any class that is not subclass of ClassLoader itself. Thus protected members of a library are not part of the public interface accessible to the client programmer. (The client programmers are those guys using the library like you and me)
However, say that we want to create a subclass of ClassLoader that load classes from a given place. The protected members are availabe for use in the subclass. If they had been private or friendly it wouldn't have been possible. If they had been public anybody could have used them.
[ February 06, 2002: Message edited by: Jose Botella ]
 
Rick Reumann
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, thanks guys. I'm still working on a handle to this from a design standpoint. Micheal, I'll look at the AWT stuff closer when I get home so I can get a better grasp on what you are describing.
I guess what I'm struggling with now is why then even make it possible to "modify a protected baseclass variable from an instance of the base class within a subclass of base that resides in the SAME package of the base class."
In other words why do the design principles break up that much when you go to another package. For example you might feasibly have a 'vehicle' package with all kinds of vehicles in it. But then maybe somewhere else a package called 'city'. Now what is so much different about a class inside of the city package extending a class from the vehicle package as opposed to a class within vehicle extended a type of vehicle from within the same package? I'm still trying to grasp it from a design standpoint.
At first I couldn't understand the reasoning behind why you shouldn't be able to access a protected variable from an instance of the base class within the subclass, but now I'm starting to wonder why you ever would want to do it even when both sub and base are in the same package?
Would there be a case ever where doing what is done in the code below at 1 !!! make any sense?
Thanks for the help with this.

[ February 06, 2002: Message edited by: Rick Reumann ]
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Suppose a Java programmer hands out a library for another programmer to use. This second programmer has to use the library from package that is not the same in which the library resides.
The public interface of the objects created from classes in that library is compound only by public members. The members that are friendly can not be called by the programmer that received the library. The members that are protected can not either. But, they could be called from the subclases of the library that the second programmer happens to create.
 
If you're gonna buy things, buy this thing and I get a fat kickback:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic