Какие из принципов SOLID используешь чаще всего?

Принципы SOLID в Flutter разработке

В практической разработке мобильных приложений на Flutter я использую все пять принципов SOLID, но некоторые более часто и явно, чем другие.

1. Single Responsibility Principle (SRP) — самый важный

Это тот принцип, который я применяю каждый день. Каждый класс и виджет должны иметь одну причину для изменения.

Плохо:

class UserModel {
  String name;
  String email;
  
  // Слишком много ответственности
  void saveToDatabase() { ... }
  void sendEmail() { ... }
  String formatForUI() { ... }
  bool validateEmail() { ... }
}

Хорошо:

class User {
  final String name;
  final String email;
}

class UserRepository {
  Future<void> save(User user) { ... }
}

class EmailService {
  Future<void> send(User user, String message) { ... }
}

class UserValidator {
  bool isEmailValid(String email) { ... }
}

Это особенно критично в Flutter при разделении бизнес-логики, хранилища данных и UI слоёв.

2. Open/Closed Principle (OCP)

Использую часто при создании расширяемых систем, особенно с фильтрами и обработчиками:

abstract class DataProcessor {
  dynamic process(dynamic data);
}

class JsonProcessor extends DataProcessor {
  @override
  dynamic process(dynamic data) => jsonDecode(data);
}

class CsvProcessor extends DataProcessor {
  @override
  dynamic process(dynamic data) => _parseCsv(data);
}

Новые процессоры добавляются без изменения существующего кода — открыто для расширения, закрыто для модификации.

3. Liskov Substitution Principle (LSP)

Важен при работе с наследованием и интерфейсами:

abstract class Storage {
  Future<void> save(String key, String value);
  Future<String?> get(String key);
}

class SharedPreferencesStorage implements Storage {
  @override
  Future<void> save(String key, String value) async { ... }
  
  @override
  Future<String?> get(String key) async { ... }
}

class HiveStorage implements Storage {
  // Полностью заменяет SharedPreferencesStorage
  @override
  Future<void> save(String key, String value) async { ... }
  
  @override
  Future<String?> get(String key) async { ... }
}

Любая реализация Storage должна работать везде, где ожидается Storage.

4. Interface Segregation Principle (ISP)

Применяю при проектировании интерфейсов, не заставляя классы реализовывать ненужные методы:

// Плохо — один большой интерфейс
abstract class MediaPlayer {
  void play();
  void pause();
  void stop();
  void record();
  void adjustVolume();
}

// Хорошо — разделённые интерфейсы
abstract class Playable {
  void play();
  void pause();
  void stop();
}

abstract class Recordable {
  void record();
}

abstract class VolumeControl {
  void adjustVolume();
}

5. Dependency Inversion Principle (DIP)

Использую постоянно, особенно с паттернами вроде Service Locator или Dependency Injection:

// Плохо — прямая зависимость
class UserBloc extends Cubit<UserState> {
  final _repository = UserRepository();
}

// Хорошо — инверсия зависимостей
class UserBloc extends Cubit<UserState> {
  final UserRepository repository;
  
  UserBloc({required this.repository});
}

// Использование
final repository = UserRepository();
final bloc = UserBloc(repository: repository);

Практическое применение

В реальных проектах я чаще всего фокусируюсь на SRP и DIP, так как они дают максимальный эффект для:

• Тестируемости кода
• Переиспользования компонентов
• Простоты рефакторинга
• Командной разработки

Остальные три принципа (OCP, LSP, ISP) применяются более избирательно, в зависимости от архитектурных решений проекта. Ключ — не переусложнять, применяя SOLID только там, где это действительно необходимо и приносит пользу.