Есть ли отличие, если дочерний класс не final?

Ключевое отличие: возможность дальнейшего наследования

Краткий ответ: Да, фундаментальное отличие есть. Класс, помеченный ключевым словом final, запрещает наследование, становясь "конечной точкой" в иерархии классов. Если дочерний класс не объявлен как final, то от него, в свою очередь, можно унаследовать другие классы, создавая более глубокую иерархию.

Давайте разберем это подробнее на примерах и рассмотрим последствия и причины использования финализаторов.

Сравнительная таблица: Final vs Non-Final

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

Рассмотрим базовый класс Vehicle и два подкласса.

// Базовый класс
class Vehicle {
    func description() -> String {
        return "Я транспортное средство."
    }
}

// 1. НЕФИНАЛЬНЫЙ дочерний класс – от него МОЖНО унаследовать
class Car: Vehicle {
    override func description() -> String {
        return "Я автомобиль."
    }
    // Дополнительные методы и свойства Car...
}

// Это РАБОТАЕТ: можно создать "внучатый" класс от Car
class SportsCar: Car {
    override func description() -> String {
        return "Я спортивный автомобиль."
    }
}

// 2. ФИНАЛЬНЫЙ дочерний класс – от него НЕЛЬЗЯ унаследовать
final class Bicycle: Vehicle {
    override func description() -> String {
        return "Я велосипед."
    }
}

// Эта строка вызовет ОШИБКУ компиляции:
// "Inheritance from a final class 'Bicycle'"
// class ElectricBicycle: Bicycle { } // 🚫 Компилятор не пропустит

Почему важно это понимать: ключевые последствия

1. Проектирование и архитектура (Основная причина)

Объявление класса final — это сигнал другим разработчикам (и вам в будущем), что вы считаете этот класс логически завершенным. Это элемент контроля за расширяемостью системы.

• Нужна глубокая иерархия (например, Vehicle -> Car -> SportsCar)? Не используйте final на промежуточных звеньях.
• Хотите гарантировать, что сложная логика класса (например, безопасная работа с сетевым запросом или шифрованием) не будет нарушена в подклассах? Объявите его final.

2. Производительность (Второстепенная, но важная причина)

Механизм динамической диспетчеризации (полиморфизм) требует дополнительных накладных расходов во время выполнения: система ищет правильную реализацию метода в иерархии классов. Если компилятор Swift видит final класс или final метод, он может заменить динамический вызов на статический, что приводит к небольшому, но измеримому приросту производительности.

class Optimizable {
    // Компилятор может "встроить" этот вызов, если класс или метод final
    final func criticalCalculation() -> Int {
        return 42
    }
}

3. Безопасность и тестируемость

final классы проще мокировать в unit-тестах. Поскольку от них нельзя наследоваться, вы гарантированно тестируете именно ту логику, которая в них заложена, без риска, что в проект просочится подкласс с измененным поведением.

Рекомендации по использованию

Современный подход в iOS-разработке на Swift склоняется к минимализму в наследовании. Часто используются протоколы и композиция. Поэтому хорошей практикой считается:

1. Начинать с final. Объявляйте класс final по умолчанию.
2. Убирать final только при необходимости. Если в процессе проектирования становится ясно, что класс должен стать базовым для специализации — просто уберите ключевое слово. Это безопаснее, чем наоборот.
3. Использовать final для leaf-классов (листьев иерархии). Если класс находится на самом нижнем уровне вашей логической иерархии, почти всегда делайте его финальным.

Итог: Отсутствие модификатора final у дочернего класса — это явно разрешенная возможность для расширения вашего кода через наследование. Наличие final — это осознанное ограничение, которое повышает стабильность, безопасность и производительность конкретного компонента. Выбор зависит исключительно от замысла архитектуры.