Pull to refresh

Comments 10

Реплика в зал.

Я видел, как DI используется совершенно бездумно, просто потому, что это модно и кошерно сегодня, как завтра будет модно что-то другое.

Например, в одном внутреннем проекте одной фирмы каждый релиз билдился с нуля целиком и никогда в течение жизни ни одна зависимость не менялась. Но этих run-time зависимостей были сотни и сотни. Вопрос - зачем? Зачем так усложнять проект, если все зависимости по сути статические?

Чтобы прогать на интерфейсах и писать тесты?

Интерфейсы это прекрасно, но они вовсе не предполагают всю DI выносить в рантайм. Тесты писались на тестовых стендах с абсолютно тем же набором бинарников и конфигов зависимостей. Но даже если нужно менять что-то для тестов, это явно не сотни независимых зависимостей.

прогать на интерфейсах

А без DI нельзя прогать на интерфейсах что ли?

interface X { ... };
class A implements X { ... };
const someX: X = new A();
function foo(x: X) { ... };
foo(new A());

Котлин не знаю, сорян.

писать тесты

Тоже можно без DI, только вместо альтернативного composition root будут моки классов. Опять же, может, в Котлине дела иначе обстоят, я хз.

Без DI у Вас не получилось. Вы написали то что делает обычный IOC контейнер, но в ручную.

Ну и в примитивном случае "прогать на интерфейсах" можно. но что если вложенность будет хотя бы 3?

и "const someX: X = new A();" - это уже не "прогать на интефейсах", а жесткая завязка на реализацию interface X, что усложнит как минимум тестирование.

Если под "статическими зависимостями" имеется ввиду хранение их в статике, то утверждение ваше ложное в условиях android проектов. Зависимости требуют ограниченного времени жизни. Их может быть и сто тысяч, но на время использования приложения может понадобиться, например, только 100, и это реальный случай.

Утверждение о неизменности очень зависит от проекта и специфика задач, поэтому приводить один единственный проект из опыта как аргумент к чему-то - считаю не совсем корректным.

Именно один проект. Потому что каждую технологию надо применять строго по требованиям конкретного проекта. Андроид это или что-то еще, значения вообще не имеет.

Где тут run-time зависимости? Как вы без DI тесты юнит тесты пишете?

Еще раз, это сильно зависит от проекта.

Я так понял, это какой-то пет проект (библиотека). Хелоу ворлд в мир велосипедов? :) Я к чему интересуюсь, прочитал про постановку задачи, красивое, но зачем и почему?

Sign up to leave a comment.