Почему использование 'final' в классе действительно так плохо?

Я занимаюсь рефакторингом старого сайта PHP OOP.

Мне так хочется начать использовать 'final' на классах для " make it explicit that the class is currently not extended by anything". Это может сэкономить много времени, если я приду в класс, и мне интересно, могу ли я переименовать / удалить / изменить protectedсвойство или метод. Если я действительно хочу расширить класс, я могу просто удалить ключевое слово final, чтобы разблокировать его для расширения.

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

Все это кажется разумной идеей, позволяющей сэкономить время ... но я часто читал, что занятия должны быть окончательными только в редких / особых случаях.

Может быть, это портит создание объекта Mock или имеет другие побочные эффекты, о которых я не думаю.

Чего мне не хватает?

Я часто читал, что уроки должны быть окончательными только в редких / особых случаях.

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

Таким образом, использование finalпо умолчанию ни в коем случае не плохо. На самом деле, многие люди предполагают, что это должно быть по умолчанию, например, Джон Скит .

Может быть, это испортило создание Mock объекта ...

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

Если вы хотите оставить себе примечание о том, что у класса нет подклассов, то обязательно сделайте это и используйте комментарий, вот для чего они. Ключевое слово «final» - это не комментарий, а использование языковых ключевых слов просто для того, чтобы что-то сигнализировать вам (и только вы когда-либо знаете, что это значит) - плохая идея.

Есть хорошая статья о том, «Когда объявлять классы окончательными» . Несколько цитат из этого:

TL; DR: Делайте ваши классы всегда final, если они реализуют интерфейс, и никакие другие открытые методы не определены

Почему я должен использовать final?

1. Предотвращение массивной цепочки наследства судьбы
2. Обнадеживающая композиция
3. Заставить разработчика задуматься о публичном API пользователя
4. Заставить разработчика сократить публичный API объекта
5. finalКласс всегда может быть расширяемым
6. extends нарушает инкапсуляцию
7. Вам не нужна эта гибкость
8. Вы можете изменить код

Когда следует избегать final:

Финальные занятия эффективно работают только при следующих допущениях:

1. Существует абстракция (интерфейс), которую реализует последний класс
2. Все общедоступные API финального класса являются частью этого интерфейса.

Если одно из этих двух предварительных условий отсутствует, то вы, вероятно, достигнете момента времени, когда вы сделаете класс расширяемым, поскольку ваш код действительно не полагается на абстракции.

PS Спасибо @ocramius за отличное чтение!

«окончательный» для класса означает: вы хотите подкласс? Давай, удаляй «финал», подкласс сколько хочешь, но не жалуйся мне, если он не работает. Ты сам по себе.

Когда класс может быть разделен на подклассы, это поведение, на которое полагаются другие, должно быть описано в абстрактных терминах, которым подчиняются подклассы. Вызывающие должны быть написаны, чтобы ожидать некоторую изменчивость. Документация должна быть написана тщательно; Вы не можете сказать людям «посмотрите на исходный код», потому что исходный код еще не там. Это все усилия. Если я не ожидаю, что класс находится в подклассе, это ненужное усилие. «final» ясно говорит, что эти усилия не были предприняты, и дает справедливое предупреждение.

Одна вещь, о которой вы, возможно, и не задумывались, это тот факт, что ЛЮБОЕ изменение класса означает, что он должен пройти новое QA-тестирование.

Не отмечайте вещи как окончательные, если вы действительно, действительно не имеете это в виду.

Использование 'final' лишает свободы других, которые хотят использовать ваш код.

Если код, который вы пишете, предназначен только для вас и никогда не будет выпущен для широкой публики или для клиента, то вы, конечно, можете делать со своим кодом то, что вы хотите. В противном случае вы не позволите другим использовать ваш код. Слишком часто мне приходилось работать с API, который было бы легко расширять для моих нужд, но потом мне мешал «финал».

Кроме того, часто есть код, который лучше не делать private, но protected. Конечно, privateозначает «инкапсуляция» и скрывает вещи, которые считаются деталями реализации. Но, как программист API, я мог бы также задокументировать тот факт, что метод xyzсчитается деталью реализации и, таким образом, может быть изменен / удален в будущей версии. Поэтому каждый, кто будет полагаться на такой код, несмотря на предупреждение, делает это на свой страх и риск. Но он действительно может сделать это и повторно использовать (надеюсь, уже протестированный) код и быстрее найти решение.

Конечно, если реализация API с открытым исходным кодом, можно просто удалить «финал» или сделать методы «защищенными», но затем вы изменили код и должны отслеживать изменения в форме патчей.

Однако, если реализация с закрытым исходным кодом, вы остаетесь с поиском обходного пути или, в худшем случае, с переключением на другой API с меньшими ограничениями в отношении возможностей для настройки / расширения.

Обратите внимание, что я не считаю, что 'final' или 'private' - это зло, но я думаю, что они используются слишком часто, потому что программист не думал о своем коде с точки зрения повторного использования и расширения кода.