Что такое SOLID и как эти принципы применяются в разработке на Dart/Flutter?

SOLID — это набор из пяти принципов объектно-ориентированного дизайна, направленных на создание понятного, гибкого и поддерживаемого кода. Вот как я применяю их в контексте Dart/Flutter:

1. S — Принцип единственной ответственности (Single Responsibility): Класс должен иметь одну и только одну причину для изменения.

   // Плохо: Класс занимается и бизнес-логикой, и работой с сетью.
   class UserManager {
     Future<User> fetchUser() async { /* сетевой запрос */ }
     void validateUser(User user) { /* валидация */ }
   }
   
   // Хорошо: Разделяем ответственность.
   class UserApiService {
     Future<User> fetchUser() async { /* сетевой запрос */ }
   }
   class UserValidator {
     void validate(User user) { /* валидация */ }
   }

2. O — Принцип открытости/закрытости (Open/Closed): Классы должны быть открыты для расширения, но закрыты для модификации.

   // Используем абстракцию (интерфейс).
   abstract class PaymentProcessor {
     void processPayment(double amount);
   }
   class StripeProcessor implements PaymentProcessor { ... }
   class GooglePayProcessor implements PaymentProcessor { ... }
   // Чтобы добавить новый способ оплаты, мы создаем новый класс,
   // а не меняем существующий код.

3. L — Принцип подстановки Барбары Лисков (Liskov Substitution): Объекты подклассов должны быть заменяемы на объекты суперкласса без нарушения работы программы.

   // Класс `Square` не должен наследовать от `Rectangle`, если изменение
   // ширины у квадрата не меняет высоту, нарушая контракт прямоугольника.
   // Вместо этого лучше общий интерфейс `Shape` с методом `area()`.

4. I — Принцип разделения интерфейса (Interface Segregation): Много специализированных интерфейсов лучше, чем один универсальный.

   // Плохо: Виджет вынужден реализовывать ненужные методы.
   abstract class OldFancyWidget {
     void build();
     void animate();
     void playSound();
   }
   // Хорошо: Разделяем интерфейсы.
   abstract class Buildable { Widget build(); }
   abstract class Animatable { void animate(); }
   // Класс реализует только то, что ему нужно.

5. D — Принцип инверсии зависимостей (Dependency Inversion): Зависимости должны строиться на абстракциях, а не на деталях.

   // Прямая зависимость от реализации (плохо):
   class DataService {
     final SqlDatabase _database = SqlDatabase(); // Жесткая привязка
   }
   // Зависимость от абстракции (хорошо):
   class DataService {
     final Database _database; // Абстракция
     DataService(this._database); // Внедрение зависимости (DI)
   }
   // Это упрощает тестирование (можно подменить `Database` моком) и смену реализации.

В Flutter эти принципы естественным образом применяются при использовании внедрения зависимостей (через provider, get_it), проектировании виджетов и бизнес-логики (Bloc/Cubit), что делает код более тестируемым и адаптивным к изменениям.