Mida sa tead SOLID-i D põhimõtte kohta?

Dependency Inversion Principle (DIP) ütleb:

• Kõrgema taseme moodulid ei tohiks sõltuda madalama taseme moodulitest. Mõlemad tüübid moodulitest peaksid sõltuma abstraktsioonidest.
• Abstraktsioonid ei tohiks sõltuda üksikdetailidest. Detailid peaksid sõltuma abstraktsioonidest.

SOLID-i D eesmärk on kõrgel tasemel poliitikate ja madala taseme teostuse eraldamine (decoupling). Selle asemel, et kõrge taseme moodul sõltuks otse madala taseme konkreetse teostuse kohta, mõlemad sõltuvad ühest liidesest või abstraktsest klassist. See suurendab paindlikkust, testitavust ja hooldatavust.

Flutteris avaldub see sageli abstraktsete klasside või miksinate kasutamisel lepingute määratlemiseks, mida seejärel rakendavad konkreetsed klassid. Näiteks andmetega töötades:

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

// Madala taseme teostus (konkreetne detail)
class ApiDataService implements DataService {
  @override
  Future<List<String>> getData() async {
    // Andmete saamise loogika API-st
    return ['API Data 1', 'API Data 2'];
  }
}

// Teine madala taseme teostus (teine detail)
class LocalDataService implements DataService {
  @override
  Future<List<String>> getData() async {
    // Andmete saamise loogika kohalikust salvestusest
    return ['Local Data 1', 'Local Data 2'];
  }
}

// Kõrgema taseme moodul, mis sõltub abstraktsioonist, mitte detailidest
class DataManager {
  final DataService _dataService; // Sõltuvus abstraktsioonist

  DataManager(this._dataService); // Sõltuvuse sisestus (inversioon)

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

// Kasutamine
void main() {
  final apiService = ApiDataService();
  final localService = LocalDataService();

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

  // ... kasutamine apiManager või localManager
}