Comments 5
Я, конечно, дико извиняюсь, но первое, что вижу в коде – жёстко прописанные зависимости CounterDepsNode
от CounterManager
и CounterStateHolder
. Как это мокать, например?
Тут очень просто все мокать. Достаточно создать интерфейс для необходимой зависимости
class CounterDepsNode extends DepsNode {
late final counterManager = bind<ICounterManager>(
() => CounterManager(
counterStateHolder(),
),
);
...
}
abstract interface class ICounterManager {
void increaseBy(int count);
}
class CounterManager implements ICounterManager {
final CounterStateHolder _counterStateHolder;
const CounterManager(this._counterStateHolder);
@override
void increaseBy(int count) {
for (int i = 0; i < count; i++) {
_counterStateHolder.increment();
}
}
}
Более того, ты можешь сделать родителем для AuthScope какой-либо интерфейс и портировать основную логику приложения от родителя к родителю
class AuthScopeDepsNode {
final IBaseAppScope _appScope;
AuthScopeDepsNode(this._appScope);
late final counterDepsNode = bind(() => CounterDepsNode());
@override
List<Set<LifecycleDependency>> get initializeQueue = [
{
counterDepsNode,
},
];
}
class IBaseAppScope {
AuthManager get authManager;
}
class AppScopeDepsNode implements IBaseAppScope {
late final authScopeDepsNode = bind(() => AuthScopeDepsNode(this));
@override
late final authManager = bind(
() => AuthManager(
authScopeDepsNode(),
)
);
}
Спасибо за вопрос!
Достаточно создать интерфейс для необходимой зависимости
В дарт каждый класс и так интерфейс. От добавления буковки I
абсолютно ничего не меняется. Я не вижу в примере использования якобы DI фреймворка собственно инжекции зависимостей, в коде они жёстко зашиты в сам класс этого разнесчастного счётчика. Передать ему мок зависимости (скажем, стэйта) при тестировании я не могу. Дальше просто не разбирался, этого достаточно. Тем более, всё остальное очень уж напоминает FizzBuzz Enterprise Edition.
Благодарю за твое предложение! Я внес изменения в пакет. Добавил возможность перезаписывать зависимость с помощью метода overrideWith, выглядит это так:
void main() {
final depsNode = FeatureDepsNode();
// Override dependency with a mock
depsNode.featureManager.overrideWith(() => MockFeatureManager());
final featureManager = depsNode.featureManager();
// Use featureManager in tests
}
Кроме того, я добавил этот раздел в README пакета, будет проще разобраться, ссылочка: https://pub.dev/packages/flutter_sputnik_di#mocking-dependencies-with-overridewith
Если у тебя будут еще какие-нибудь вопросы или пожелания, можешь писать мне. Мои контакты есть в профиле. Спасибо.
Добра и любви)
Если у тебя будут еще какие-нибудь вопросы или пожелания
Собственно, одно пожелание, но сразу по двум совсем разным пунктам: прежде чем начинать чем-то заниматься, ознакомиться с историей вопроса:
Перед тем, как разрабатывать (и тем более, рекламировать) собственный DI фреймворк, понять, что же такое, собственно, DI. Ибо предложенное решение именно этого-то и не делает. А с последними изменениями делает криво – по прозрачности кода и количеству бойлерплэйта никакого сравнения с популярными пакетами.
Выходя на популярный ресурс, ознакомиться с принятым на нём стилем общения. Тут принято обращаться к незнакомым на Вы. Мне лично пофиг, но выглядит тут необычно, и насколько я видел, когда встречается, многих раздражает.
Новый DI фреймворк для DART и Flutter — sputnik_di