Какие плюсы и минусы сервис локатора?

Плюсы и минусы Service Locator в Flutter

Service Locator (сервис-локатор) — популярный паттерн управления зависимостями в Flutter. Наиболее известная реализация — пакет get_it. Разберу детально его преимущества и недостатки.

Что такое Service Locator?

Eто глобальный контейнер, который хранит все зависимости приложения и предоставляет доступ к ним.

import 'package:get_it/get_it.dart';

final getIt = GetIt.instance;

// Регистрация сервиса
getIt.registerSingleton<AuthService>(AuthServiceImpl());
getIt.registerSingleton<DatabaseService>(DatabaseImpl());
getIt.registerSingleton<ApiClient>(ApiClientImpl());

// Использование
class LoginPage extends StatelessWidget {
  final authService = getIt<AuthService>();
  
  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () => authService.login('user@example.com', 'password'),
      child: Text('Login'),
    );
  }
}

ПЛЮСЫ Service Locator

1. Простота и быстрота

// Просто и быстро регистрируешь зависимости
getIt.registerSingleton<UserRepository>(UserRepository());

// И используешь их везде
class UserProvider extends ChangeNotifier {
  final _repository = getIt<UserRepository>();
  
  Future<void> loadUsers() async {
    final users = await _repository.getUsers();
    notifyListeners();
  }
}

Преимущество: Минимум boilerplate кода, быстро сделать прототип.

2. Глобальный доступ

Можешь получить сервис откуда угодно без передачи параметров.

// В любом месте приложения
class NotificationHelper {
  static void showNotification(String message) {
    final logger = getIt<Logger>();  // Легко достать логгер
    logger.log('Notification: $message');
  }
}

// В диалоговом окне
class ConfirmDialog extends StatelessWidget {
  final api = getIt<ApiClient>();  // И здесь тоже
  
  void onConfirm() async {
    await api.confirmAction();
  }
}

Применение: Логирование, аналитика, конфигурация — везде нужны эти сервисы.

3. Гибкость реализации

// Разные типы регистрации

// Singleton — один экземпляр на всё приложение
getIt.registerSingleton<Database>(Database());

// Lazy singleton — создаётся только при первом обращении
getIt.registerLazySingleton<SharedPreferences>(
  () => SharedPreferences.getInstance(),
);

// Factory — новый экземпляр каждый раз
getIt.registerFactory<Logger>(() => Logger());

// Async инициализация
getIt.registerSingletonAsync<FirebaseAuth>(
  () async => await initializeFirebase(),
);

4. Легко переопределять для тестирования

// В тестах переопределяешь реальные сервисы на mock'и
setUp(() {
  // Очищаем регистрацию
  getIt.reset();
  
  // Регистрируем mock
  getIt.registerSingleton<AuthService>(MockAuthService());
  getIt.registerSingleton<ApiClient>(MockApiClient());
});

test('login should update user state', () async {
  final authService = getIt<AuthService>();
  await authService.login('test@test.com', 'password');
  expect(authService.isLoggedIn, true);
});

МИНУСЫ Service Locator

1. Скрытые зависимости (Hidden Dependencies)

// ❌ Плохо: невидно, какие зависимости нужны
class UserBloc extends Bloc<UserEvent, UserState> {
  final _userRepo = getIt<UserRepository>();
  final _authService = getIt<AuthService>();
  final _logger = getIt<Logger>();
  
  UserBloc() : super(UserInitial()) {
    // Откуда они берутся? Неясно!
  }
}

// ✅ Хорошо: явные зависимости через конструктор
class UserBloc extends Bloc<UserEvent, UserState> {
  final UserRepository _userRepo;
  final AuthService _authService;
  final Logger _logger;
  
  UserBloc(this._userRepo, this._authService, this._logger)
    : super(UserInitial()) {
    // Все зависимости видны сразу
  }
}

Проблема: Сложнее разобраться в коде, когда зависимости достаются из глобального контейнера.

2. Усложнение тестирования

// ❌ Service Locator может испортить другие тесты
setUp(() {
  getIt.registerSingleton<Database>(MockDatabase());
});

test('test 1', () async {
  // Используем DatabaseService
  final db = getIt<Database>();
  expect(db.isConnected, true);
});

test('test 2', () async {
  // Если забыл reset(), то используется старый mock!
  final db = getIt<Database>();  // Может быть старый state
});

// ✅ Лучше явные зависимости
test('test 1', () async {
  final mockDb = MockDatabase();
  final service = UserService(mockDb);
  expect(service.getUsers(), completes);
});

3. Сложность отладки

Когда приложение большое, сложно понять где и как зарегистрирована каждая зависимость.

// setup.dart — где-то в проекте
getIt.registerSingleton<ApiClient>(ProductionApiClient());

// main.dart — может быть переопределено
getIt.registerSingleton<ApiClient>(StagingApiClient());

// или в test_utils.dart
getIt.registerSingleton<ApiClient>(MockApiClient());

// Где истина? Проблема!

4. Глобальное состояние

// ❌ Service Locator — глобальное состояние
getIt.registerSingleton<AppConfig>(appConfig);

// Если что-то изменилось в appConfig, как это отследить?
appConfig.theme = 'dark';  // Где это изменение?

// ✅ Лучше использовать State Management (Provider, BLoC, Riverpod)
final themeProvider = StateNotifierProvider<ThemeNotifier, String>(
  (ref) => ThemeNotifier('light'),
);

5. Порядок регистрации важен

// ❌ Легко ошибиться с порядком
getIt.registerSingleton<Database>(Database());
getIt.registerSingleton<Repository>(Repository());  // Может требовать Database!

// Если Database не зарегистрирован до Repository, crash!

// ✅ Лучше явный порядок инициализации
final database = await Database.init();
final repository = Repository(database);

6. Сложность с асинхронной инициализацией

// ❌ Трудно управлять асинхронной инициализацией
getIt.registerSingletonAsync<ApiClient>(
  () async => await ApiClient.init(),
);

// Нужно ждать инициализации перед использованием
await getIt.allReady();

// ✅ Лучше явная инициализация с Future
Future<void> initializeApp() async {
  final apiClient = await ApiClient.init();
  // Теперь используем apiClient
}

Сравнение паттернов

Когда использовать Service Locator

✅ Используй Service Locator:

• Быстрый прототип или MVP
• Простое приложение без сложных зависимостей
• Сервисы, не требующие state management (Logger, Analytics)
• Вместе с другими паттернами (не как основной)

❌ Избегай Service Locator:

• Большой production проект
• Сложные цепочки зависимостей
• Нужна высокая тестируемость
• Работа в команде (сложно договориться об использовании)

Best Practice: Гибридный подход

// Используй Service Locator только для глобальных сервисов
getIt.registerSingleton<Logger>(Logger());
getIt.registerSingleton<Analytics>(Analytics());
getIt.registerSingleton<SharedPreferences>(prefs);

// Зависимости бизнес-логики передавай через конструктор
class UserRepository {
  final ApiClient _api;  // Явная зависимость
  final Logger _logger;
  
  UserRepository(this._api, this._logger);
}

// State Management через Provider/BLoC
final userRepositoryProvider = Provider((ref) {
  final api = getIt<ApiClient>();
  return UserRepository(api, getIt<Logger>());
});

Резюме

Service Locator — удобный инструмент для быстрой разработки, но может создать проблемы в больших приложениях. Лучший подход — использовать его для глобальных сервисов, а бизнес-зависимости передавать явно. В modern Flutter приложениях рекомендуется Riverpod или Provider вместо чистого Service Locator.