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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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