Использовать финальные классы или не использовать финальные классы? Вот в чём вопрос. А ещё в том, когда и как это делать правильно.
Почему стоит использовать финальные классы
Максимальное уменьшение области видимости
Когда вы видите у класса префикс final, вы понимаете, что этот класс не может быть расширен любым другим, что не только делает его более читаемым, но и позволяет вам быть уверенным в том, что область действия логики ограничена этим конкретным классом.
Поощрение подхода «композиция вместо наследования»
Принцип открытости/закрытости гласит: класс должен быть открыт для расширения, но закрыт для изменений.
Если по какой-либо причине (хорошо понимая саму причину) вы решите использовать наследование, тогда просто удалите ключевое слово final, и всё готово.
Если вы «по умолчанию» не можете расширять класс (потому что он финальный), вы помогаете себе, думая прежде всего об использовании композиции вместо наследования.
Почему этот класс не финальный?
Если мы стремимся к композиции, а не к наследованию, то мы должны стараться избегать наследования, насколько это возможно, и использовать его только тогда, когда это действительно необходимо. Наследование в ООП часто используется неправильно.
Заблуждения
Когда мы в первый раз изучали ООП, мы приводили классический пример наследования. Тем не менее, когда Алан Кей создал Smalltalk, наследование не было его главной концепцией. Основной концепцией был обмен сообщениями, то есть вы можете отправлять сообщения объектам, а они инкапсулируют в себе данные и логику. Вы можете изменять их поведение, используя различные объекты, что на самом деле является композицией. Но в итоге концепция наследования настолько популярна, что в конечном счёте затмевает композицию.
Выгоды от использования финальных классов
- Понятные контракты. Использование интерфейсов заставит вас мыслить в терминах связей между объектами.
- Изолированные блоки кода без побочных эффектов. Внедрение интерфейсов в качестве зависимостей устранит все неприятные побочные эффекты кода, над которым вы работаете.
- Тестируемость. Подмена на фиктивные зависимости чрезвычайно проста, если они являются интерфейсами.
- Низкая и управляемая сложность. Поскольку всё изолировано, вам не нужно беспокоиться о волнообразных изменениях. Это значительно снижает сложность вашего кода.
- Низкая когнитивная нагрузка. С уменьшением сложности ваш сможет сосредоточиться на самом важном.
- Гибкость кода. Удаляя любую ненужную связь, вы сможете рефакторить намного легче, чем раньше.
- Уверенность в себе. Возможность тестировать свой код изолированно не оставляет сомнений в правильности его изменения.
Композиция вместо наследования
- Если вы чувствуете необходимость перенастроить объект, изменить части алгоритма или переписать часть реализации, подумайте о создании нового класса вместо переопределения существующего.
- Допустим, вам нужно создать иерархию классов, где подклассы являются подходящими заменами своего родительского класса. Это была бы классическая ситуация, когда вы всё ещё можете подумать о наследовании. Однако результат может быть даже лучше, если вы наследуетесь не от конкретных родительских классов, а от абстрактных интерфейсов.
Что вам следует начать делать [вместо того что вы делаете сейчас]
- Используйте интерфейсы для определения контрактов между вашими классами.
- Используйте финальные классы для реализации поведения этих интерфейсов.
- Используйте композицию (через внедрение зависимостей посредством конструктора класса), чтобы собрать всё вместе и минимизировать сложность.
Итого: Интерфейсы → Финальные классы → Композиция
Автор: Oleg Zolotarev
