Предпочитаешь наследование или композицию?

Наследование vs Композиция: анализ парадигм проектирования в iOS-разработке

Как опытный iOS-разработчик с более чем 10-летней практикой, мой однозначный ответ: предпочитаю композицию над наследованием в абсолютном большинстве случаев. Это не просто личное предпочтение, а следствие эволюции принципов проектирования, доказавших свою эффективность в создании поддерживаемых, гибких и тестируемых приложений.

Принципиальные различия подходов

Наследование создает отношения "является" (is-a), жестко связывая классы в иерархию:

// Классический пример наследования
class Vehicle {
    func move() { print("Moving") }
}

class Car: Vehicle {
    override func move() { print("Driving") }
}

class ElectricCar: Car {
    // Наследует всю иерархию Vehicle → Car
}

Композиция строит отношения "имеет" (has-a), инкапсулируя поведение:

// Пример композиции через протоколы
protocol Engine {
    func start()
}

protocol Transmission {
    func shift()
}

class ModernCar {
    private let engine: Engine
    private let transmission: Transmission
    
    init(engine: Engine, transmission: Transmission) {
        self.engine = engine
        self.transmission = transmission
    }
    
    func drive() {
        engine.start()
        transmission.shift()
    }
}

Почему композиция предпочтительнее в современной iOS-разработке

1. Гибкость и переиспользование

   • Композиция позволяет собирать объекты из независимых компонентов
   • Поведение можно изменять динамически во время выполнения
   • Избегаем проблем "хрупкого базового класса"

2. Тестируемость

   • Компоненты легко заменяются моками в тестах
   • Изолированная ответственность каждого компонента
   • Возможность тестирования в отрыве от иерархии

3. Соблюдение принципов SOLID

   • Принцип единственной ответственности: каждый компонент решает одну задачу
   • Принцип открытости/закрытости: расширяем через новые компоненты, а не модификацию
   • Принцип инверсии зависимостей: зависим от абстракций (протоколов)

Когда наследование все же уместно

Несмотря на предпочтение композиции, наследование имеет свои обоснованные применения:

• Фреймворки Apple: UIViewController, UIView предполагают наследование
• Естественные иерархии: когда отношения действительно соответствуют "является"
• Поведение по умолчанию: базовые реализации в библиотеках

// Наследование оправдано в случае UIView
class CustomButton: UIButton {
    // Кастомизация стандартного компонента
    override func layoutSubviews() {
        super.layoutSubviews()
        // Дополнительная настройка
    }
}

Практические паттерны композиции в Swift

1. Протокол-ориентированное программирование

   protocol DataFetching {
       func fetchData(completion: @escaping (Result<Data, Error>) -> Void)
   }
   
   class DataManager {
       let fetcher: DataFetching
       let cache: Caching
       // Композиция зависимостей
   }
   

2. Композиция ViewController'ов

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

3. Функциональная композиция

   typealias DataProcessor = (Data) -> ProcessedData
   
   func createPipeline(_ processors: [DataProcessor]) -> DataProcessor {
       return { data in
           processors.reduce(data) { result, processor in
               processor(result)
           }
       }
   }
   

Заключение

Композиция обеспечивает лучшую декомпозицию, упрощает рефакторинг и делает код более предсказуемым. В современной iOS-экосистеме, особенно с широким внедрением протокол-ориентированного программирования в Swift, композиция стала доминирующей парадигмой. Однако, зрелый подход предполагает использование оба инструмента осознанно, выбирая наследование только когда он действительно отражает семантику предметной области, а не как механизм переиспользования кода. Итоговый критерий — создание понятного, поддерживаемого и гибкого кода, а не слепое следование догмам.