От какого принципа SOLID можно отказаться при разработке дизайн системы?

Отказ от принципов SOLID в дизайне системы: контекст и компромиссы

SOLID — это набор пяти принципов объектно-ориентированного программирования, направленных на создание гибких, поддерживаемых и масштабируемых систем. Однако в практике разработки, особенно в контексте iOS/Apple platforms, строгое соблюдение всех пяти принципов иногда может привести к излишней сложности, снижению производительности или непрактичным архитектурным решениям. Вопрос о том, от какого принципа можно «отказаться», требует понимания, что речь идет не об полном игнорировании, а о сознательных компромиссах в определенных контекстах, когда другие критерии (например, производительность, простота или специфика фреймворка) становятся более важными.

Наиболее спорным и часто подвергаемым критике в этом контексте является принцип Dependency Inversion (D — Dependency Inversion Principle).

Принцип инверсии зависимостей (DIP) и его компромиссы

DIP утверждает:

1. Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций.
2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

На практике это означает внедрение интерфейсов (протоколов в Swift) и использование механизмов Dependency Injection (DI).

Почему DIP может быть «ослаблен» или игнорирован в некоторых случаях:

1. Избыточность и сложность в простых сценариях: В небольших проектах, модулях или когда зависимость является стабильной и фундаментальной частью системы (например, использование UIKit или SwiftUI), создание слоя абстракций может быть непропорционально сложным.

   // Строго по DIP: абстракция для очень простой службы
   protocol DataFetcher {
       func fetchData() -> String
   }
   
   class NetworkDataFetcher: DataFetcher {
       func fetchData() -> String { return "Data from network" }
   }
   
   class ViewModel {
       let fetcher: DataFetcher // Инъекция абстракции
       init(fetcher: DataFetcher) { self.fetcher = fetcher }
   }
   
   // Более простой и прямой подход (без строгого DIP)
   class SimpleViewModel {
       func fetchData() -> String {
           let service = NetworkService() // Прямая зависимость от конкретного класса
           return service.fetch()
       }
   }
   

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

2. Проблемы производительности и накладные расходы: Использование большого количества протоколов и динамического диспетчерирования (особенно при использовании сложных контейнеров DI) может иметь накладные расходы на производительность, хотя в большинстве случаев на iOS это не критично. В высокопроизводительных вычислениях или в критических по времени участках кода (например, реальная обработка видео) прямая зависимость от оптимизированного конкретного класса может быть предпочтительнее.

3. Специфика фреймворков и платформ Apple: Многие API UIKit, CoreData, Metal и других фреймворков являются конкретными классами, а не интерфейсами. Создание абстракций над ними иногда может быть нецелесообразным, потому что:

   • Это добавляет дополнительный слой, который нужно поддерживать.
   • Может затруднить использование специфических, мощных функций фреймворка.
   • Некоторые системные классы уже являются de facto «абстракциями» в своей области (например, UIViewController как абстракция управления view).

4. Увеличение количества кода и времени разработки: Следование DIP требует создания протоколов, фабрик, инжекторов. В условиях жестких сроков или для прототипирования это может быть непрактично.

Важные выводы и альтернативы

• Отказ — это компромисс, не правило: Отходить от DIP (или любого другого принципа SOLID) следует сознательно, понимая риски для поддерживаемости и тестируемости в будущем.
• Контекст определяет решение: В долгосрочных проектах с большой командой и необходимостью частых изменений DIP крайне важен для гибкости. В одноразовых скриптах или демо-проектах его можно упростить.
• Частичное применение: Можно применять DIP только к ключевым, изменяемым компонентам системы (например, к слою работы с данными), а не к каждому классу.
• Использование других паттернов: Вместо сложных систем DI иногда можно использовать Factory Method, Service Locator или даже Singleton (с осторожностью) для управления зависимостями, что является более легким, но менее гибким вариантом.

Таким образом, принцип Dependency Inversion чаще всего становится предметом дискуссий о компромиссах. Однако важно помнить, что другие принципы SOLID (например, Single Responsibility или Open/Closed) являются более фундаментальными и их нарушение обычно приводит к более серьезным проблемам в архитектуре даже в небольших проектах. Отказ от любого принципа должен быть взвешенным решением, основанным на конкретных требованиях проекта, а не на общем правиле.