В каком принципе SOLID не обойтись без интерфейсов

Ответ: Зависимость от абстракций (Dependency Inversion Principle)

Из пяти принципов SOLID именно Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) невозможно реализовать без использования интерфейсов (или абстракций в виде абстрактных классов в некоторых языках). DIP — это ключевой принцип, который буквально требует опираться на абстракции, а не на конкретные реализации.

Суть принципа DIP

DIP состоит из двух утверждений:

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

На практике это означает, что класс, содержащий бизнес-логику (модуль высокого уровня), не должен напрямую создавать или использовать экземпляры конкретных классов, отвечающих за работу с базой данных, сетью, файловой системой и т.д. (модули низкого уровня). Вместо этого он должен работать только с интерфейсами (абстракциями).

Почему без интерфейсов не обойтись? Практический пример

Рассмотрим типичный нарушенный DIP пример и его исправление.

Нарушение DIP (прямая зависимость от деталей):

// Модуль низкого уровня
class SqlDatabase {
    fun save(data: String) {
        // Конкретная логика сохранения в SQL БД
    }
}

// Модуль высокого уровня напрямую зависит от деталей низкого уровня
class BusinessLogicService {
    private val database = SqlDatabase() // Прямое создание зависимости!

    fun executeBusinessOperation(data: String) {
        // Какая-то бизнес-логика...
        database.save(data) // Прямой вызов конкретного метода
    }
}

Здесь BusinessLogicService жестко привязан к SqlDatabase. Смена базы данных или добавление кэширования потребует переписывания BusinessLogicService.

Соблюдение DIP (зависимость от абстракций через интерфейс):

// 1. Абстракция (интерфейс), от которой зависят ВСЕ модули
interface DataRepository {
    fun save(data: String)
}

// 2. Модуль низкого уровня зависит от абстракции и реализует её
class SqlDatabase : DataRepository {
    override fun save(data: String) {
        // Конкретная реализация для SQL
    }
}

class FileSystemStorage : DataRepository {
    override fun save(data: String) {
        // Конкретная реализация для файлов
    }
}

// 3. Модуль высокого уровня зависит ТОЛЬКО от абстракции
class BusinessLogicService(private val repository: DataRepository) { // Зависимость внедряется извне (DI)
    fun executeBusinessOperation(data: String) {
        // Бизнес-логика остается неизменной...
        repository.save(data) // Работает через абстракцию
    }
}

// 4. Конфигурация зависимостей (обычно в точке входа или DI-контейнере)
fun main() {
    // Мы можем легко подменить реализацию, не меняя BusinessLogicService
    val serviceWithSql = BusinessLogicService(SqlDatabase())
    val serviceWithFile = BusinessLogicService(FileSystemStorage())
    // Или даже мок для тестов!
    val serviceForTest = BusinessLogicService(mockk<DataRepository>())
}

Ключевые выводы и преимущества

• Интерфейс — это контракт. Он формализует абстракцию, без которой DIP остался бы лишь теоретической идеей.
• Слабое зацепление (Loose Coupling). Модули высокого и низкого уровня ничего не знают о конкретных реализациях друг друга, они знают только об общем контракте.
• Гибкость и расширяемость. Новую реализацию (например, CloudStorage) можно добавить, просто имплементировав интерфейс DataRepository. Основная бизнес-логика останется нетронутой.
• Тестируемость. Принцип позволяет легко подменять реальные зависимости Mock-объектами или Stub-ами в unit-тестах, что невозможно при прямой зависимости от конкретных классов.
• DIP лежит в основе инъекции зависимостей (Dependency Injection) и многих паттернов проектирования, таких как Стратегия, Наблюдатель, Адаптер.

Таким образом, Принцип инверсии зависимостей является абсолютным лидером по необходимости использования интерфейсов. Без них он просто невыполним, так как именно интерфейсы выступают в роли тех самых абстракций, на которые должны опираться все модули системы. Остальные принципы SOLID (например, Open/Closed или Liskov Substitution) могут использовать интерфейсы для своей реализации, но DIP без них принципиально невозможен.