final или не final
 

Использовать ли final при объявлении чего-либо. В одних источниках я читал, что это загружает код, в других - что делает его быстрее, так как его нельзя продолжить. Стоит ли его использовать постоянно? А не только тогда, когда необходимы специальные классы и функции, которые нельзя наследовать.

я бы предпочел вообще обходится без final, так работать интересней

Иногда необходимо, чтобы классы нельзя было расширить. Так часто делает и сама Adobe почти со всеми классами.

Можно поприменять при использовании "Шаблонного метода", чтобы не спутать какие методы предназначены для перегрузки а какие нет.

А целый класс финалить, чтобы нельзя было расширить - зачем это может понадобиться?
Только если вы хотите намекнуть коллегам:
"Не ребят, даже не пытайтесь, этот класс безнадежен, он чудом вообще работает и если вы хотите на нём что-то построить - то это будет генератор багов"

А, более адекватная причина:
Класс A используется в классе B хитрым образом с завязкой на реализацию именно этого класса А
и если в класс B вы попытаетесь подставить наследника класса А - он развалится нафиг. Так что не пытайтесь.

Короче, final-изация класса применяется, когда есть проблемы с дизайном.

Что-то у меня не получилось засечь разницу между скоростью обращения к финализированному и нефинализированному методу
Может потому, что тестировал на дебажной версии флешплеера (сборка swf-ки была релизная)
Целиком финализированный класс не тестил.

Lyso, это вы автор топика This или не this?
Вопрос риторический...

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

Так вот, ТАМ где вы узнали про этот оператор должно было рассказываться для каких целей он применяется. Если хотите чтобы наследовался - не пишите final, хотите обратного - пишите. Или вы пытаетесь найти в операторе final подвох или спасение? Там нет ни того ни другого, просто конкретная функциональность.

P.s. Adobe НИКОГДА без причины не закрывают возможность наследования того или иного предопределенного класса.

Вообще-то с единичными.

Например, представьте себе следующую ситуацию: некоторый класс A является DataProvider`ом для класса B. Класс B честно ждёт загрузки данных (события Event.COMPLETE), после чего мирно начинает работать. Но злые гномы подсунули вместо класса A его наследника, ExtendedA, который шмаляет этот самый Event.COMPLETE каждую секунду. Мирного экземпляра класса B увозят в психушку. Занавес.

Примерно для таких ситуаций и нужен final. Но я сторонник того, что бензопила круче лобзика, и то что к первой надо читать инструкцию и думать меня не останавливает. Поэтому final я не пишу никогда.

P.S. final на скорость никак не влияет. Это даже наивно думать, что компилятор делает какие-то "преобразования", закрывая "отросток" (таблицу виртуальных функций, видимо), который позволяет получить прирост в скорости. Даже если бы такое закрытие существовало - компилятор бы находил сам финальных наследников и перед компиляцией помечал бы их как final. final — это самозавязка рук, и не более.

Типичая ситуация, когда нужен final - тогда же, когда бы вы, например, использовали константу. Объекту очень редко нужны такие методы (мне ни разу не понадобились), как и не-статические константы (такими, как ни странно, часто пользуюсь, но в целом это не общепринятая практика). А статические / функции объявленные вне класса и так по факту final.

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

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

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

Если же в одиночку за неделю пишется проект на два десятка классов, то словом "final" можно не заморачиваться.

Классная парадигма, однако. Т.е. запрещаем цепочки наследования больше 1-го яруса на уровне соглашения по кодированию :) Но что-то глядя на flex-фреймворк кажется что такое невозможно. Да и в Qt говорят длиннющие цепочки наследования.
Неужели заставить кодеров не выбиваться за 1 ярус наследования реально?

Я бы так уверен не был, наш FlexSDK-компилятор даже выражение
_не_ шибко старается привести к
http://gskinner.com/talks/quick/#43

да и такие оптимизации в идеале должен компилятор делать - у него для этого достаточно информации:
http://gskinner.com/talks/quick/#47

Хм, не слышал. А в чем смысл такого подхода?