Search
Write a publication
Pull to refresh

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

Если у тебя будут еще какие-нибудь вопросы или пожелания, можешь писать мне. Мои контакты есть в профиле. Спасибо.

Добра и любви)

Если у тебя будут еще какие-нибудь вопросы или пожелания

Собственно, одно пожелание, но сразу по двум совсем разным пунктам: прежде чем начинать чем-то заниматься, ознакомиться с историей вопроса:

  1. Перед тем, как разрабатывать (и тем более, рекламировать) собственный DI фреймворк, понять, что же такое, собственно, DI. Ибо предложенное решение именно этого-то и не делает. А с последними изменениями делает криво – по прозрачности кода и количеству бойлерплэйта никакого сравнения с популярными пакетами.

  2. Выходя на популярный ресурс, ознакомиться с принятым на нём стилем общения. Тут принято обращаться к незнакомым на Вы. Мне лично пофиг, но выглядит тут необычно, и насколько я видел, когда встречается, многих раздражает.

Sign up to leave a comment.

Articles