|
|
|||||
final или не final
Использовать ли final при объявлении чего-либо. В одних источниках я читал, что это загружает код, в других - что делает его быстрее, так как его нельзя продолжить. Стоит ли его использовать постоянно? А не только тогда, когда необходимы специальные классы и функции, которые нельзя наследовать.
|
|
|||||
Регистрация: Dec 2006
Сообщений: 1,764
|
я бы предпочел вообще обходится без final, так работать интересней
__________________
а за окном атлантический океан! |
|
|||||
Иногда необходимо, чтобы классы нельзя было расширить. Так часто делает и сама Adobe почти со всеми классами.
|
|
|||||
Можно поприменять при использовании "Шаблонного метода", чтобы не спутать какие методы предназначены для перегрузки а какие нет.
А целый класс финалить, чтобы нельзя было расширить - зачем это может понадобиться? Только если вы хотите намекнуть коллегам: "Не ребят, даже не пытайтесь, этот класс безнадежен, он чудом вообще работает и если вы хотите на нём что-то построить - то это будет генератор багов" А, более адекватная причина: Класс A используется в классе B хитрым образом с завязкой на реализацию именно этого класса А и если в класс B вы попытаетесь подставить наследника класса А - он развалится нафиг. Так что не пытайтесь. Короче, final-изация класса применяется, когда есть проблемы с дизайном. Цитата:
Может потому, что тестировал на дебажной версии флешплеера (сборка swf-ки была релизная) Целиком финализированный класс не тестил. Последний раз редактировалось expl; 07.05.2011 в 20:03. |
|
|||||
Регистрация: Aug 2010
Сообщений: 86
|
Lyso, это вы автор топика This или не this?
Вопрос риторический... Знаете, не в обиду конечно, но складывается впечатление что вы там где-то открываете для себя новый оператор, ранее незнакомый, и решаете поспрашивать о нем на форуме. Так вот, ТАМ где вы узнали про этот оператор должно было рассказываться для каких целей он применяется. Если хотите чтобы наследовался - не пишите final, хотите обратного - пишите. Или вы пытаетесь найти в операторе final подвох или спасение? Там нет ни того ни другого, просто конкретная функциональность. P.s. Adobe НИКОГДА без причины не закрывают возможность наследования того или иного предопределенного класса. |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Например, представьте себе следующую ситуацию: некоторый класс A является DataProvider`ом для класса B. Класс B честно ждёт загрузки данных (события Event.COMPLETE), после чего мирно начинает работать. Но злые гномы подсунули вместо класса A его наследника, ExtendedA, который шмаляет этот самый Event.COMPLETE каждую секунду. Мирного экземпляра класса B увозят в психушку. Занавес. Примерно для таких ситуаций и нужен final. Но я сторонник того, что бензопила круче лобзика, и то что к первой надо читать инструкцию и думать меня не останавливает. Поэтому final я не пишу никогда. P.S. final на скорость никак не влияет. Это даже наивно думать, что компилятор делает какие-то "преобразования", закрывая "отросток" (таблицу виртуальных функций, видимо), который позволяет получить прирост в скорости. Даже если бы такое закрытие существовало - компилятор бы находил сам финальных наследников и перед компиляцией помечал бы их как final. final — это самозавязка рук, и не более.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Modus ponens
|
Типичая ситуация, когда нужен final - тогда же, когда бы вы, например, использовали константу. Объекту очень редко нужны такие методы (мне ни разу не понадобились), как и не-статические константы (такими, как ни странно, часто пользуюсь, но в целом это не общепринятая практика). А статические / функции объявленные вне класса и так по факту final.
Я объявляю как final приватные классы (т.е. классы объявленные в том же файле, но вне пакета) не чтобы запретить наследование, а чтобы констатировать факт, что наследовать их уже никак не получится (для документации).
__________________
Hell is the possibility of sanity |
|
|||||
[+1 23.05.11]
Регистрация: Dec 2001
Сообщений: 4,159
|
Случай "я написал *****код и помечу его final, чтобы не было еще хуже" рассматривать не будем -- оно само отсыхает со временем.
Есть парадигма проектирования (запамятовал название), согласно которой любой класс должен быть либо абстрактным, либо финальным. Если класс абстрактный -- он специально спроектирован под расширение. Если класс финальный -- мы можем не заботиться о том, что кто-то может заоверрайдить метод и нарушить всю логику. Мне случилось пару лет поработать с принципиальными сторонниками этого принципа. По результатам могу сказать, что в больших проектах это существенно повышает стабильность. Если же в одиночку за неделю пишется проект на два десятка классов, то словом "final" можно не заморачиваться.
__________________
GIT d++ s++:++ a C++$ UB++ P++ L+ E+ W+++ N++ w++ O+ M V- t-- 5-- X+ R+++ tv- b+++ D++ |
|
|||||
Классная парадигма, однако. Т.е. запрещаем цепочки наследования больше 1-го яруса на уровне соглашения по кодированию Но что-то глядя на flex-фреймворк кажется что такое невозможно. Да и в Qt говорят длиннющие цепочки наследования.
Неужели заставить кодеров не выбиваться за 1 ярус наследования реально? Цитата:
_не_ шибко старается привести к http://gskinner.com/talks/quick/#43 да и такие оптимизации в идеале должен компилятор делать - у него для этого достаточно информации: http://gskinner.com/talks/quick/#47 Последний раз редактировалось expl; 08.05.2011 в 00:00. |
|
|||||
Регистрация: May 2010
Сообщений: 543
|
Цитата:
__________________
Вы грабите бедных людей. Парень со свирелью накажет вас. Хонгильдон (с) |
Часовой пояс GMT +4, время: 10:33. |
|
« Предыдущая тема | Следующая тема » |
Теги |
final , код , скорость , функция |
|
|