Какие принципы SOLID ты знаешь и применяешь в Dart/Flutter?

Question

Какие принципы SOLID ты знаешь и применяешь в Dart/Flutter?

Тип вопроса: SOLID и принципы Вероятность: 29% Категория: Flutter Разработчик

Ответ

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

S (Single Responsibility): Класс должен иметь одну и только одну причину для изменения. В Flutter это означает разделение логики: Widget отвечает за отрисовку, а Bloc, ChangeNotifier или сервис — за бизнес-логику и состояние.
```
// ПЛОХО: Виджет и логика загрузки данных вместе.
// ХОРОШО: Виджет использует `UserRepository` или `UserCubit`, которые отвечают за получение данных.
```

O (Open/Closed): Классы должны быть открыты для расширения, но закрыты для модификации. Достигается через использование абстракций (интерфейсов, абстрактных классов) и композиции.

abstract class PaymentProcessor { Future<void> pay(double amount); }
class StripeProcessor implements PaymentProcessor { ... }
class PayPalProcessor implements PaymentProcessor { ... }
// Класс `CheckoutService` зависит от `PaymentProcessor` и не меняется при добавлении новых способов оплаты.

L (Liskov Substitution): Объекты подкласса должны быть заменяемы объектами родительского класса без нарушения работы программы. В Dart это строго контролируется системой типов.
```
// Если `Bird` имеет метод `fly()`, то `Penguin`, не умеющий летать, не должен наследовать `Bird`.
// Вместо этого можно создать более общий класс `Animal` или интерфейс `Walkable`.
```
I (Interface Segregation): Много специализированных интерфейсов лучше одного общего. В Dart нет ключевого слова interface, но его роль выполняют абстрактные классы без реализации или обычные классы (контракт).
```
// Вместо одного `Worker` с методами `work()`, `eat()`, `sleep()`.
abstract class Workable { void work(); }
abstract class Eatable { void eat(); }
// Класс `Robot` реализует только `Workable`, а `Human` — оба интерфейса.
```

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

class UserService {
  final UserRepository repository; // Зависим от абстракции
  UserService(this.repository); // Внедрение через конструктор
  Future<User> getUser(int id) => repository.fetchUser(id);
}
// `UserRepository` может быть `ApiUserRepository`, `LocalUserRepository` или мок для тестов.

Применение этих принципов в Flutter особенно важно при использовании архитектур вроде Clean Architecture или при работе с состоянием (Provider, Riverpod, Bloc).

Ответ 18+ 🔞

Да ты послушай, что за модная хрень эта SOLID! Ну, типа, не просто так её придумали, а чтобы код твой не превращался в такое пиздопроебище, в котором через месяц сам чёрт ногу сломит. Сейчас разжую, как есть, без зауми.

S — Принцип одной ответственности (Single Responsibility) Ёпта, это же элементарно, Ватсон! Одна штука — одно дело. Не надо из виджета в Flutter'е и данные качать, и в базу писать, и ещё анимацию крутить. Это ж манда с ушами получится! Виджет пусть рисует, а за логику пусть отвечает какой-нибудь Cubit или ChangeNotifier. Смотри, как просто:

// ПЛОХО: Виджет-универсал, который всё умеет. Хуй с горы, а не класс.
// ХОРОШО: Виджет просто рисует, а данные ему кто-то умный (репозиторий, кубит) приносит.

O — Принцип открытости/закрытости (Open/Closed) Суть в том, что твой класс должен быть как хороший конструктор: ты можешь добавлять новые детали (расширять), но сам базовый блок переделывать не надо (закрыт для модификации). Достигается через интерфейсы, абстрактные классы. Добавил новый способ оплаты — написал новый класс, а старый код даже не чихнул.

abstract class PaymentProcessor { Future<void> pay(double amount); }
class StripeProcessor implements PaymentProcessor { ... }
class PayPalProcessor implements PaymentProcessor { ... }
// Сервис оплаты работает с абстракцией PaymentProcessor. Хоть моржовым хуем плати — ему похуй.

L — Принцип подстановки Барбары Лисков (Liskov Substitution) Звучит сложно, а на деле: если ты заявляешь, что твой класс — это птица, то он должен уметь всё, что умеет птица. Нельзя назвать пингвина наследником класса Bird с методом fly(), а потом охуевать, что он не летает. Это нарушение контракта, доверия ебать ноль. Либо делай более общий класс, либо интерфейс Swimmable.

I — Принцип разделения интерфейса (Interface Segregation) Не делай один жирный интерфейс на все случаи жизни! Это как заставлять робота реализовывать метод eat(). Чихать он хотел на твой бутерброд! Лучше сделай несколько маленьких и точных. Робот реализует Workable, а человек — и Workable, и Eatable. Все довольны, терпения ноль ебать ни у кого.

D — Принцип инверсии зависимостей (Dependency Inversion) Вот это, бля, основа основ для адекватного тестирования и гибкости. Не цепляйся за конкретные реализации, цепляйся за абстракции! Твой сервис не должен знать, откуда приходят данные — с сервера или из локальной базы. Он должен знать только интерфейс репозитория.

class UserService {
  final UserRepository repository; // Зависим от абстракции, а не от "этого твоего АПИ"
  UserService(this.repository); // Подсунули что надо в конструктор
  Future<User> getUser(int id) => repository.fetchUser(id);
}
// Для прода — ApiUserRepository, для тестов — MockUserRepository. Красота!

Если эти принципы применять в Flutter с тем же Riverpod или Bloc, то жить становится проще. Код не рассыпается от каждого чиха, и подозрение ебать чувствуешь не к нему, а к тем, кто его не соблюдает.