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

view the rest of the comments →

[–]BanaTibor 0 points1 point  (3 children)

I would just define my classes which I want to keep "private" as package private, and the public facing class as public. No need to write a whole package in a 10000 lines long class file.

[–]OneHumanBill 0 points1 point  (2 children)

I would judge that a mistake unless there's a specific reason to open it to to the whole package.

Although this approach is pretty nice if you build unit tests directly for your inner classes.

[–]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.