Наилучшая практика для модификаторов конструктора в Guice

Question

Теперь я читаю Guice's official document. И они говорят

Как коррекции, просто ограничить видимость обеих ваших реализации классов, и их конструкторы. Обычно пакет частное является предпочтительным для обоих, так как это способствует:

связывания класса в модуле в том же пакете

блок тестирования класса с помощью средств прямого конкретизации

Как простой, мнемонические помните, что public и @Inject подобны эльфам и гномам: они могут работать вместе, но в идеальном мире они будут сосуществовать самостоятельно.

Я знаю, насколько опасно public constructor, читая документ. И цитируемое предложение представляется решением, но я не уверен в точном значении. Итак, вы могли бы проверить, правильна ли моя мысль или нет.

Во-первых, они говорят, что связывают класс в рамках модуля в том же пакете. Это означает, например, что у вас есть пакет в системе. И хорошо использовать Module, соответствующий пакету? Итак, в основном у вас одинаковое количество Module s и столько же пакетов?

Во-вторых, вы можете увидеть модуль тестирования класса с помощью прямого инстанцирования. Это означает, что мы должны выполнять модульное тестирование класса с использованием прямого экземпляра, а не GuiceModule? Я думаю, что Guice также полезен для тестирования, особенно для тестирования модулей, как они сказали.

Я немного смущен, может ли кто-нибудь дать мне понять?

Answer 1

Во-первых, они говорят, что связывают класс внутри модуля в том же пакете. Это означает, например, что у вас есть пакет в системе. И хорошо ли использовать модуль, соответствующий пакету? Итак, в основном у вас одинаковое количество модулей и одинаковое количество пакетов?

Да. Вы все равно должны использовать пакеты. Использование пакета по умолчанию не рекомендуется для всех, кроме программ размером с игрушку.

я обычно ожидать, чтобы иметь org.whatever.foo.some.feature пакет с классом модуля под названием FeatureModule (то есть имя пакета + Module, а не конкретно FeatureModule).

Во-вторых, вы можете видеть модуль, тестирующий класс с помощью прямого инстанцирования. Это означает, что мы должны выполнять модульное тестирование класса с использованием прямого экземпляра, а не модуля Guice's? Я думаю, что Guice также полезен для тестирования, особенно модульного тестирования, как они сказали.

Просто проще видеть, что именно вы тестируете, если вы непосредственно вводите то, что хотите проверить.

Уверенный, вы можете использовать guice, но есть определенное количество «магии происходит здесь» со связями, которые могут скрыть неожиданное поведение в тесте.

Это относится к модульным испытаниям; если вы проводите интеграционное тестирование, вы, вероятно, захотите использовать что-то близкое к тому, как это делает ваш производственный код, который может включать в себя guice.