Почему для внедрения зависимости используются публичные методы?

Question

Почему для внедрения зависимостей используются открытые методы? Поправьте меня, если я ошибаюсь, но можно изменить реализацию, используя рефлексию.

Answer 1

DI не самоцель.Цель DI - включить слабую связь через , отдавая предпочтение композиции, а не наследованию, , и это возможно только в том случае, если вы предоставите открытый API для этой цели.

Нельзя перекомпоновывать компоненты в новые испособы выхода без публичного API.

Answer 2

DI-фреймворки имеют много способов внедрения зависимостей

• конструктор инъекций
• сеттер впрыска
• инициализатор впрыска
• полевая инъекция

Используя первые три, с модификатором public вы можете установить зависимости вручную, даже если класс используется вне структуры DI.

Однако 4-й вариант широко используется. Наиболее распространенным сценарием, в котором вам может потребоваться вручную установить зависимости, являются модульные тесты. Для этой весны, например, предлагает ReflectionTestUtils, так что вы можете вводить в поля с 1 строкой, и это более или менее хорошо.

Answer 3

Просто чтобы уточнить ответ, который дал ColinD (я даже не знал о закрытых пакетах классах до года программирования на Java). Я полагаю, что с приложением, разработанным на основе DI, вы сделаете интерфейсы общедоступными и, возможно, некоторые абстрактные классы и Enums:

package org.my.service;

public interface Service {
    public void process();
}

Тогда конкретная реализация будет приватной (без общедоступного ключевого слова)

package org.my.service;

class RealService {
    public void process() {/*do something*/}
}

Это реализует концепцию сокрытия информации и означает, что детали реализации не проникают в публичный API. Это также означает, что вы не можете использовать класс за пределами этого пакета (ошибка времени компиляции, если вы попытаетесь - вы не можете «создать» его где-либо).

Опять же, как сказал ColinD, вы можете выполнить юнит-тестирование, потому что ваш юнит-тест будет находиться в org.my.service.

Answer 4

Имейте в виду, что политика безопасности может препятствовать вызову защищенных, пакетных или закрытых методов даже через API отражения.Если структура DI должна работать в всех средах, то она может полагаться только на общедоступные методы.

Answer 5

Это довольно общее утверждение, и оно не соответствует действительности. Обычно я предпочитаю использовать конструкторы частного пакета (или публичные конструкторы в закрытых классах пакета, поскольку это не имеет значения) для внедрения зависимостей, поскольку это позволяет вам создавать экземпляры и внедрять класс самостоятельно (без отражения или инжектора) для тестирование в тестовом классе в той же упаковке.