Насколько важно не потерять инкапсуляцию на уровне пакета?

#java #ооп

                    
Я пишу проект на java. Создавал все классы в одном пакете и в один момент их количество
достигло 20. И это только те, которые отвечают за GUI. тогда я решил что надо разбить
их по пакетам :) Многие из этих классов - это мои наследники классов Swing - MyScroll,
MyButton и т.д. Всего около 10 таких классов. Их используют другие 10 классы, занимающиеся
непосредственно построением GUI. Сейчас эти 10, которые являются наследниками классов
Swing у меня не являются публичными. А если я их вынесу в отдельный пакет их придется
сделать публичными. Очень интересно стоит ли их выносить и какие вообще могут быть
рекомендации по этой теме? Ведь с одной стороны, проект будет лучше структурирован,
с другой стороны я  потеряю инкапсуляцию на уровне пакета, правильно? Гуглил - не нашел.
В книгах тоже - просто сухой текст насчет того что такое пакеты, как их создавать и
как импортировать. А хотелось бы поглубже разобраться.
    

Ответы

Ответ 1

20 классов в пакете — это в целом не очень много. К примеру, в Java-8 в пакете java.util
116 файлов .java (не считая подпакетов). Поэтому пока повода для беспокойства нет.

Не забывайте про другой способ организации исходников: можно использовать вложенные
классы. Если, например, в вашем пакете com.example есть классы, рисующие интерфейс
MyButton, MyLabel и есть некий главный класс типа MyWindow или MyFrame, часто разумно
вспомогательные классы разместить внутри:

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


Такой код проще читать: понятно, что MyButton и MyLabel используются только MyFrame.
Конечно, тут тоже надо знать меру: если вложенных классов много, размер исходника вырастет
до некомфортных размеров.

Альтернативный подход — использовать модульную систему типа OSGi, где каждый jar
— это отдельный модуль или плагин, который может определить (в файле MANIFEST.MF) экспортируемые
и неэкспортируемые пакеты. Тогда вы можете иметь com.example, содержащий публичные
классы, и, например, com.example.internal, содержащий детали реализации. Классы из
internal будут тоже объявлены публичными, но плагин не будет экспортировать этот пакет,
поэтому из других плагинов в OSGi-приложении он не будет доступен. 

Что-то подобное нам предложит Java-9 и проект Jigsaw: там можно будет создать файлик
module-info.java и написать, какие пакеты видны за пределами данного модуля.


Ответ 2

Честно говоря, не очень понятна структура проекта и по этому сложно прямо вот так
дать какую-то рекомендацию. Логично предположить, что кто-то из классов, которые отвечают
за построение GUI, должен быть виден наружу, просто для того, чтобы запустить отрисовку.
Можно например вынести их в отдельный пакет и сделать package private, а затем, например,
создать там же какой-нибудь public class GUIBuilder с методом build(), который будет
запускать всю процедуру. Лично я выношу классы в отдельный пакет для группировки функционала