Ответ 1
Понимание возможностей Scala
Во-первых, нам нужно понять возможности и ограничения каждой стратегии модуляции.
Пакеты
Они работают так же, как в Java. Вы можете использовать много файлов для объявления разных частей одного пакета, и вы можете вложить много уровней в глубину. Это обеспечивает максимальную гибкость вашего макета. Однако, поскольку загрузчики классов по умолчанию ожидают, что будут только найти классы и интерфейсы в пакетах, все Scala позволяет вам помещать туда. (Классы, черты и объекты.)
Объекты
Объекты могут содержать что угодно: методы, поля, другие объекты, классы, черты и т.д. Подклассы, черты и объекты на самом деле являются их собственными отдельными объектами с содержащим объектом как префикс с наименованием (в соответствии с JVM). Объект должен содержаться полностью внутри одного файла, и хотя вы можете вложить подклассы произвольно глубоко, это делается путем извлечения более длинных имен, а не добавления в путь для загрузчика классов.
Объекты пакета
Проблема с наличием только объектов и пакетов заключается в том, что вам может понадобиться вложенная структура:
scala.xml
scala.xml.include
scala.xml.include.sax
чтобы вам нужно было использовать пакеты (чтобы не иметь один гигантский файл и тревожные имена классов). Но вы также можете захотеть
import scala.xml._
чтобы сделать для вас различные константы и неявные преобразования, чтобы вам нужно было использовать объект. объекты пакета приходят на помощь; они по существу те же, что и обычные объекты, но когда вы говорите
import scala.xml._
вы получаете как все в пакете (scala.xml._), так и все в соответствующем объекте пакета (scala.xml.package).
Как модулировать код
Теперь, когда мы знаем, как работает каждая часть, существуют довольно очевидные правила организации:
- Поместите связанный код в пакет
- Если есть много связанных частей, поместите их в подпакеты
- Если пакет требует implicits или констант, поместите их в объект пакета для этого пакета
- Если у вас есть ветвь ветки вашей иерархии пакетов, то это ваш выбор в отношении того, должен ли он быть объектом или объектом пакета. Есть несколько вещей, которые не разрешены для объектов пакета (хотя список все меньше уменьшается - я не уверен, что что-то осталось, кроме запрета на затенение других имен в пакете), поэтому обычный объект может быть лучшим выбором. Пока вы не беспокоитесь о совместимости с двоичными файлами, легко изменить свой разум позже - просто измените
objectнаpackage objectв большинстве случаев.