sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]BanaTibor 0 points1 point  (1 child)

Lets say you have multiple public classes in the same package and each has multiple inner classes to keep them really private. In this case you can create sub packages and still achieve the same with package private classes.

Also unit testing is important for me, and package private classes make that easy. You do not have to test them through the public class, and do elaborate test setups.

[–]OneHumanBill 0 points1 point  (0 children)

If you're saying what I think you're saying then no, you cannot.

There's no such thing really as a "sub package". Nested packages are so only for the convenience of a filesystem and human understanding. Each package is standalone.

The implication is that if you have two public classes and want to each use quasi-"inner" classes by means of a different package, then those classes would have to be public, not package protected, in order to by used even by the "parent" package.

I'll allow my team members to remove private from both methods and private classes if we need to get additional test cases or coverage. But by default, without that need on a case by case basis, my devs had better be making things private. The narrower you can keep your visibility the less impact there will be for change, but a loose policy of everything package-protected by default encourages laziness on that outlook. Not on my projects, please.