How important is it not to lose the collection on the package level?

[Jolied]

I'm writing a project for java. Created all classes in one package, and at one point they reached 20. And that's just the ones who are responsible for the GUI. Then I thought I should break them over the bags. Many of these classes are my heirs of Swing - MyScroll, MyButton, etc. Just about 10 of these classes. They are used by the other 10 classes directly involved in GUI construction. Now these 10, which are the heirs of Swing class, are not public. And if I put them in a separate package, they'll have to be made public. It was very interesting whether they should be made and what recommendations could be made on the topic at all? On the one hand, the project will be better structured, on the other hand, I will lose my collection at the packing level, right? Google didn't. In the books, too, it's just a dry text about what bags are like to create them and how to import them. I'd like to figure it out.

[Alberto]

20 classes in the package are not much. For example, in Java-8 in a package. java.util 116 files .java (not including sub-packages). So there's no reason to worry.

Don't forget the other way of organizing the source: you can use the assigned classes. If, for example, in your package. com.example There are classes drawing interfaces. MyButton♪ MyLabel and there's a major class, MyWindow or MyFrameoften reasonably auxiliary classes within:

public class MyFrame extends JFrame {
    private static class MyButton extends JButton { ... }
    private static class MyLabel extends JLabel { ... }
    ...
}

It's easier to read: MyButton and MyLabel only MyFrame♪ Of course, there's a need to know what's going on here: if there's a lot of classes invested, the size of the originator will grow uncomfortable.

The alternative approach is to use a modular OSGi system where each jar is a separate module or flame that can be identified (in MANIFEST.MF) with exportable and non-exportable packages. Then you can have com.examplecontaining public classes and, for example, com.example.internalcontaining details of implementation. Classes internal It will also be announced in public, but the flame will not export this package, so it will not be available from other forms to the OSGi application.

Something like that will be offered to us by Java-9 and Jigsaw Project: there will be a file. module-info.java and write which packages are visible outside the module.