final или не final

[wvxvw]

Можно вообще все только статическими методами написать
EDIT: а, не, не получится стейдж получить, а так бы можно было

[honest_man]

Конечно можно, а еще можно просто на джаваСкрипте фигачить, чего уж там, нам ооп вообще ненужно! =)

[expl]

Вот так вот, java-script уже не ООП-язык

[honest_man]

expl, ну что вы. Просто я осветил стадии деградации. Сначала переходим на жава скрипт, а потом и вовсе бросаем ооп.

[i.o.]

Сначала переходим на экшн скрипт, а потом и вовсе бросаем ооп.

эээм... забываетесь, сэр-с?

[Psycho Tiger]

Я бы так уверен не был, наш FlexSDK-компилятор даже выражение

Я знаю. Я просто как бы намекаю, что во всех вселенных это не даст прироста к скорости)

[honest_man]

*** honest_man в страхе быть забитым любителями JS. =)

Сообщение от i.o.

эээм... забываетесь, сэр-с?

К стати да, попутал рамсы... Но вовремя вспомнил на каком форуме нахожусь и откорректировался! )

[Crazy]

Сообщение от expl

Классная парадигма, однако. Т.е. запрещаем цепочки наследования больше 1-го яруса на уровне соглашения по кодированию

Hint: никто не запрещает наследовать один абстрактный класс от другого абстрактного класса.

Добавлено через 11 минут

Сообщение от carrotoff

А в чем смысл такого подхода?

Смысл такого подхода в отказе от бесконтрольного наследования. Де-факто человек, проектирующий обычный класс, как правило не задается вопросом "что будет, если от этого класса будут наследоваться". Пример: программист A пишет класс C1 для своих текущих целей. Через неделю программист B пишет класс C2, расширяющий C1 и переопределяющий пару методов. Спустя полгода программист A переделывает класс C1, вследствие чего в поведении C2 начинают проявляться жестокие глюки. Поскольку при переделке C1 автору и в голову не придет найти все производные классы и проверить, как на них повлияет правка. Просто жизненный факт.

Разделение abstract-final позволяет это упорядочить. Если пишется abstract-класс -- автор заранее пишет его под наследование. Соответственно, при внесении изменений в абстрактный класс нельзя тупо забыть, что от него наследуются.

P.S. Вообще, следует понимать, что наследование реализации -- довольно опасная операция.

[honest_man]

Сообщение от Crazy

P.S. Вообще, следует понимать, что наследование реализации -- довольно опасная операция.

Наследование реализаций - это частые и вынужденные меры. Зачем повторять код? Если программисты A и B сидят на одной трубе, не стоит им в тихую (по шухерски ) наследовать классы друг друга.

Как по мне, в данной ситуации, это рефакторинг - опасная операция. А может просто программист А поссорился с программистом В?

[expl]

Hint: никто не запрещает наследовать один абстрактный класс от другого абстрактного класса.

А, ну тогда здесь нет ничего сверъестественного.
Когда надо получить класс с похожим функционалом обычно от него никто не наследуется, а выносят базовый класс для обоих. Так просто проще.
А тут их просто еще финалят для верности.

Наследование реализаций - это частые и вынужденные меры. Зачем повторять код? Если программисты A и B сидят на одной трубе, не стоит им в тихую (по шухерски ) наследовать классы друг друга.

При выносе общего класса кода может быть даже меньше из-за того, что не потребуется перегружать в коде B специфичные для А методы и мусора в коде B будет меньше.

Как по мне, в данной ситуации, это рефакторинг - опасная операция.

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

А может просто программист А поссорился с программистом В?

А что это меняет?