Ko vari pastāstīt par SOLID principa D?

Atkarības inversijas princips (Dependency Inversion Principle) saka:

• Augšējā līmeņa moduļiem nevajadzētu būt atkarīgiem no apakšējā līmeņa moduļiem. Abi moduļu tipi būtu jāatkarīgs no abstrakcijām.
• Abstrakcijas nevajadzētu būt atkarīgām no detaļām. Detaļas būtu jāatkarās no abstrakcijām.

D mērķis SOLID ir atdalīt (decoupling) augstākā līmeņa politiku no zemākas līmeņa īstenošanas. Tā vietā, lai augstākā līmeņa modulis tieši atkarīgs no zemāk līmeņa moduļa konkrētās īstenošanas, abi ir atkarīgi no kopēja interfeisa vai abstrakta klases. Tas palielina elastību, testējamību un uzturēšanas vieglumu.

Flutter bieži tas izpaužas, izmantojot abstraktus klases vai miksinus, lai definētu līgumus, kurus pēc tam īsteno konkrētas klases. Piemēram, strādājot ar datiem:

// Abstrakcija
abstract class DataService {
  Future<List<String>> getData();
}

// Zemākas līmeņa īstenošana (konkrēts detalizācija)
class ApiDataService implements DataService {
  @override
  Future<List<String>> getData() async {
    // Datu iegūšanas loģika no API
    return ['API Data 1', 'API Data 2'];
  }
}

// Cita zemākas līmeņa īstenošana (cits detalizācija)
class LocalDataService implements DataService {
  @override
  Future<List<String>> getData() async {
    // Datu iegūšanas loģika no vietējās glabāšanas
    return ['Local Data 1', 'Local Data 2'];
  }
}

// Augstākā līmeņa modulis, kas ir atkarīgs no abstrakcijas, ne no detaļām
class DataManager {
  final DataService _dataService; // Atkarība no abstrakcijas

  DataManager(this._dataService); // Atkarības injekcija (inversija)

  Future<List<String>> fetchData() {
    return _dataService.getData();
  }
}

// Izmantošana
void main() {
  final apiService = ApiDataService();
  final localService = LocalDataService();

  final apiManager = DataManager(apiService); // Injekcija ApiDataService
  final localManager = DataManager(localService); // Injekcija LocalDataService

  // ... izmanto apiManager vai localManager
}