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

А, SOLID, говоришь? Ну, это как раз та тема, где без принципов — нихуя не разберёшься, а с ними — хоть какой-то порядок в бардаке. Слушай, я тебе на пальцах, но с кодом, объясню, как это в нашем флаттерском деле выглядит.

S — Принцип единственной ответственности. Это, блядь, основа основ. Один класс — одна работа. Не надо делать из него швейцарский нож, который и данные тянет, и валидирует, и в БД пихает, и ещё чайник ставит. Ёпта, смотри:

// Вот это — пиздопроебибна. Класс-универсал, который за всё отвечает. Изменять его — волнение ебать.
class UserManager {
  Future<User> fetchUser() async { /* полез в сеть */ }
  void validateUser(User user) { /* проверяет почту */ }
  void saveToPrefs(User user) { /* пихает в кэш */ }
}

// А вот — уже лучше. Разделили, как взрослые.
class UserApiService {
  Future<User> fetchUser() async { /* только сеть */ }
}
class UserValidator {
  void validate(User user) { /* только валидация */ }
}
class UserCache {
  void save(User user) { /* только сохранение */ }
}

Каждый теперь знает своё место. Меняешь логику кэша — трогаешь только UserCache. Доверия ебать ноль к тем, кто пишет монстров на 500 строк.

O — Принцип открытости/закрытости. Звучит как хуй в пальто, но смысл простой: ты должен иметь возможность добавлять новый функционал, не перелопачивая старый, проверенный код. Расширять — можно, ломать — нельзя.

// Допустим, у нас оплата. Вместо этого ужаса:
class PaymentService {
  void pay(String type, double amount) {
    if (type == 'stripe') { /* код на страницу */ }
    else if (type == 'google_pay') { /* ещё код */ }
    else if (type == 'qiwi') { /* овердохуища условий */ }
    // Завтра добавят "крипту" — придёшь и тут всё ебёшь.
  }
}

// Делаем по-человечески. Абстракция, Карл!
abstract class PaymentProcessor {
  void processPayment(double amount);
}

class StripeProcessor implements PaymentProcessor {
  @override void processPayment(double amount) { /* только Stripe */ }
}
class GooglePayProcessor implements PaymentProcessor { /* только Google Pay */ }
// Захотел добавить Qiwi? Без проблем! Создал новый класс `QiwiProcessor`.
// Старый код даже не чихнул. **Чих-пых тебя в сраку**, костылистые if-else!

L — Принцип подстановки Лисков. Тут главное — не наебать систему наследования. Если уж класс B — потомок класса A, то его должно быть можно впихнуть везде, где ожидается A, и ничего не должно разъебаться.

Классический пример — квадрат и прямоугольник. Если наследовать Square от Rectangle, то получается манда с ушами: у квадрата ширина и высота меняются вместе, а у прямоугольника — нет. Нарушается контракт. Поэтому лучше не мухлевать, а сделать общий интерфейс Shape с методом area(). Сам от себя охуел, когда это осознал.

I — Принцип разделения интерфейса. Не заставляй класс реализовывать то, что ему нахуй не сдалось. Лучше много маленьких и точных интерфейсов, чем один жирный, от которого всех тошнит.

// Вот это — интерфейс-монстр. Хочешь простую кнопку? Всё равно тащи на себе анимацию и звуки.
abstract class OldFancyWidget {
  void build();
  void animate();
  void playSound();
  void showTooltip();
}

// А вот — цивилизация.
abstract class Buildable { Widget build(); }
abstract class Animatable { void animate(); }
abstract class Soundable { void playSound(); }

// Твоя кнопка теперь реализует только `Buildable`. Хочешь анимацию? Добавь `Animatable`.
// Никакого лишнего груза. **Да похуй** на ненужные методы.

D — Принцип инверсии зависимостей. Это, пожалуй, самое важное для тестируемого и гибкого кода. Высокоуровневые модули не должны зависеть от низкоуровневых деталей. Оба должны зависеть от абстракций.

// Прямая и жёсткая зависимость. Хуй сменишь базу данных без боли.
class DataService {
  final SqlDatabase _database = SqlDatabase(); // Прикипел намертво.
}

// Абстракция и внедрение зависимости (DI). Красота!
abstract class Database {
  Future<void> saveData(String data);
}

class DataService {
  final Database _database; // Держимся за абстракцию.
  DataService(this._database); // Зависимость приходит извне.
}

// Теперь в продакшене ты прокидываешь `SqlDatabase`, а в тестах — `MockDatabase`.
// Всё работает. Код не знает и не ебёт, что там под капотом. **Удивление пиздец**, как же это удобно.

Вот так эти принципы в Flutter и живут. Когда используешь provider, get_it или riverpod для инверсии зависимостей, проектируешь бизнес-логику в Cubit'ах — ты по сути постоянно применяешь эти правила. Сначала кажется, что терпения ноль ебать на всё это архитектурное геморроение, но потом, когда нужно что-то поменять или потестить, понимаешь — оно того стоит. Код не рассыпается от одного чиха, а живёт и поддается изменениям.