• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Public v Package access

 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can I implement my database access functions defined by DBAccess with package level access or does this change the interface.
Cheers
Tony
[ September 11, 2003: Message edited by: Tony Collins ]
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Tony,
I also have URLy Bird. My interface is called DBMain. You wrote:

Can I implement my database access functions defined by DBAccess with package level access or does this change the interface.

I will not change the access level if I were you. Why do you want to do that? It might cause the automated testing software to not work. Is it worth the risk?
Regards.
Bharat
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A notice in Max's book that every class's methods have public access, and not package access. Does anyone understand the advantage of publishing the interface of classes that aren't required outside the package ?
Or is it just safer that way
Tony
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
Which classes, in particular, are you thinking about?
M
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're implementing an interface, all methods in the interface are public, period. Even if you omit the access modifier, it's still considered public. So you can never implement them with any less public access modifier. That's jut the way the language is set up.
If you nonetheless want to limit the socpe of in interface to a package, you can achieve this by making ihe interface itself a non-public. E.g.

Aside from interfaces, is there value in making method public when they're only used inside a package? Mmmm, hard to say. I tend to make things either public or private, forgetting about the other two levels unless there's a specific need for them. So my classes have a lot of public methods that could really be made package-level I suppose. I think the interfaces influence my thinking here - once the use of interfaces forces methods a(), b(), c() to be public, then other methods d(), e(), f() seem like they should be public too, just for consistency, even if they're not in interfaces and they aren't currently used outside the package. I only use package or protected access if there's a method which I have been forced to share with other classes which is nonetheless risky if called by outsiders. I suppose I could use these more often.
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the db package all classes are public, but what is the advantage of having DVD and DVDDatabase public.
In the gui package all classes are public but doesn't the application runner have to be the only public class.
Am I missing something or is packaging redundant if all the classes in a package are public. Fogive me I'm new to java and have previouslly only worked in C/C++ which doesn't really use packaging.
Additionally I have the packages
db contains db access
gui - client & server gui
rmiconnection - connection factory
propertiesmanager - all logic and prompts for updating and retrieving properties
Does this seem OK or is the properties manager stuff better of in te gui package.
Cheers
Tony
[ September 11, 2003: Message edited by: Tony Collins ]
 
Jack Conway
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I try to use "package" classes wherever I can. I only make a class public if there is a justification for it. Encapsulation, just at a higher level than class level.
If a class is "package", the it is really irrelevant whether the methods inside are "package" or "public", because if a client can't see the class, it can't see the methods (even if they're public).
So, for example, my Data class is "package private", even though the methods in the Sun interface it implements are public.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Am I missing something or is packaging redundant if all the classes in a package are public. Fogive me I'm new to java and have previouslly only worked in C/C++ which doesn't really use packaging.
Well you still get the conceptual convenience of grouping related classes together in a directory. It makes it easier to find things. And you have the option of hiding things at package-level access in the future, even if you're not currently using it. You may have refactored in the past, or will in the future, so that the package is more directly used for data hiding. The fact that it isn't used to provide data hiding now isn't necessarily grounds to refactor things to remove a package entirely (presumably dumping its contents into an existing package.)
Additionally I don't understand why protected members can be accessed across the package as well as by the sub-class of the class they are in.
Simplicity, I think. This allows us to rank access levels linearly:
private -> [package] -> protected -> public
Here I can say that these levels are increasingly public. Each level contains all the access privileges of the prios level, and more. If protected members were not accessible from elsewhere in the package, and package members were not accessible from subclasses, then neither level would be more or less public than the other; they'd be a bit more confusing, IMO.
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cheers for all the help. I can see know that packages can be used both for the distrubution of classes and avoidence of namespace polution( as in C++) and for further constriction of access.
Tony
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic