Какой принцип SOLID может быть ослаблен при проектировании дизайн-системы компонентов и почему?

В контексте дизайн-системы компонентов (например, на UIKit/SwiftUI) часто ослабляется Принцип инверсии зависимостей (Dependency Inversion Principle - DIP).

Почему?

1. Конкретные зависимости: Компоненты дизайн-системы (кнопки, текстовые поля) часто жестко привязаны к конкретным фреймворкам (UILabel, UIButton, View из SwiftUI). Абстрагирование этих базовых элементов через протоколы может создать избыточную сложность без реальной пользы.
2. Стабильность платформы: Базовые фреймворки (UIKit/SwiftUI) являются стабильными и редко меняемыми зависимостями. Риск, от которого защищает DIP (частая смена реализации), здесь минимален.
3. Производительность и нативная интеграция: Прямое использование нативных компонентов обеспечивает лучшую производительность и полный доступ ко всем их возможностям, что может быть затруднено через слой абстракции.

Пример (без строгого следования DIP):

// Компонент дизайн-системы использует конкретный UIKit-класс
struct PrimaryButton: UIViewRepresentable {
    var title: String
    func makeUIView(context: Context) -> UIButton {
        let button = UIButton(type: .system)
        button.setTitle(title, for: .normal)
        button.backgroundColor = .systemBlue // Конкретная настройка
        return button // Возвращаем конкретный тип
    }
    ...
}

Важно: Это не означает полный отказ от DIP. Принципы единой ответственности (SRP), открытости/закрытости (OCP) и разделения интерфейсов (ISP) остаются критически важными для создания гибких, переиспользуемых и поддерживаемых компонентов.