Best practice regarding package-private or public classes

Question

Hello,
If I was, for example, developing a library that client code would use and rely on, then I can see how I would design the library as a "module" contained in its own package,
and I would certainly want to think carefully about what classes to expose to outside packages (using "public" as the class access modifier), as such classes would represent the
exposed API. Any classes that are not part of the API would be made package-private (no access modifier). The package in which my library resides would thereby create an
additional layer of encapsulation.
However, thus far I've only developed small applications that reside in their own packages. There does not exist any "client code" in other packages that relies on the code I've
written. In such a case, what is the best practice when I choose to make my classes public or package-private? Is it relevant?
Thanks in advance!

Answer 1

Jujubi wrote:
...However, thus far I've only developed small applications that reside in their own packages. There does not exist any "client code" in other packages that relies on the code I've
written. In such a case, what is the best practice when I choose to make my classes public or package-private? Is it relevant?I've always gone by this rule of thumb: Do I want others using or is it appropriate for others to use my methodes. Are my methods "pure" and not containing package speicific coding. Can I guarentee that everything will be initialized correctly if the package is included in other projects.
Basically--If I can be sure that the code will do what it is supposed to do and I've not "corrupted" the obvious meaning of the method, then I usually make it public--otherwise, the outside world, other packages, does not need to see it.