Посмотрел запись доклада Алименкова про ООП и ненужность наследования, надо бы прокомментировать что-то.
Вот ссылка на его видео: https://www.youtube.com/watch?v=G6LJkWwZGuc, предлагаю посмотреть, прежде чем вайнить :3
Вкратце, автор осуждает наследование, считает что оно зло, предлагает заменять на композицию.
Имхо, чтобы начать понимать наследование, нужно почитать немного википедию, вспомнить основы матлогики и сделать простейшие выводы о том, как мир выглядит сквозь призму ООП-моделирования. После этого тебе уже не нужна лекция Алименкова, ты можешь смотреть на любые вещи, предметы, события, и видеть их сквозь ООП. Смотришь на стол, ложку и мужской половой предмет - и везде видишь теоремы об изоморфизме в записи Java-классами.
Вместо этого для большинства коллег сейчас ООП - это кода ты в IDE протыкал кнопочку «отнаследоваться от класса и переопределить вот такие методы», когда функциональности существующего класса не хватает. Особенно хорошо видно на собеседованиях: тебя спрашивают какую-то чепуху типа «всех методов ArrayList» (вероятно чтобы потом нажать кнопочку «доопределить»), а о самой сути работы, которая как раз есть ООП моделирование, почему-то не спрашивают.
И потом при написании кода начинается история про слепых мудрецов, натолкнувшихся на слона. Только они не хотели изучить слона, они сразу хотели на нем ездить, или хотя бы чтобы он не мешал им пройти. В результате такой вверх ногами постановки возникают странные языки без ООП и метопрограммирования просто для того, чтобы его не было. Вот эти анонимные филды, вложенные структуры в Гошке. Слон, не мешай проезду.
В качестве примера, мне кажется важным: ООП в Java есть продукт теории типов, и она хорошо решает ситуации, когда нужно разобраться с чем-то типа полиморфизма подтипов. Отсюда принципы SOLID, в частности принцип подстановки Лисков.
Но как только люди начинают задавать вопросы типа «а вдруг в этом классе добавятся-убавятся методы» (типичный пример про хэшмеп, в базовый класс которого добавился метод addAll, реализованный как попало), это уже объект внимания совершенно другой по структуре и сложности области. Например, темпоральной логики. И в Java нет никаких встроенных методов решения проблем темпоральной логики.
Есть модель памяти и конкаренси, но это про другое, она отвечает на вопрос, какое в данный момент значение имеет символ, и это не вопрос высокоуровневого дизайна программы, а вопрос разряда «ой, ёпть, чота всё сломалось». У меня есть ощущение, что джава - это скорей о снапшотах, и создании ощущения что мир состоит из снапшотов, чтобы скрыть от глаз страшный реальный мир.
И понимая это, ты приходишь к проблеме конструирования мета-языка поверх Java. Например, правил SOLID (одно из которых говорит, что на каждое мажорное изменение нужно создавать новый класс), или специальных фреймворков (не знаю специальных, наверняка есть, но например в Spring есть своя особенная внутренняя философия на эту тему). Или решать вопрос выходя из границ языка, с помощью пакетного менеджера Linux. Или что-то гибридное, версии бандлов в OSGi. И всё это обмазать системой деплоя, которая реально будет работать в настоящем времени, например, Ansible.
Одного фреймворка будет мало. Даже если это Акка. Фреймворки ложатся на фреймворки, и получается инфраструктура, элементы которой синергетически влияют друг на друга. Таким образом цепочки из десятков классов есть не кривой дизайн, а внешнее отражение внутренне сложной для моделирования области, растянутой в пространстве, времени, конях и людях. Наверное, какая-то очень небольшая часть этих проблем на Haskell это было бы красивее, но это уже другой разговор.
И вот к чему это. Утверждение «наследование - это плохо» - это немного неверно. Наследование не нужно без всего остального. Слепым мастерам, джедаям всех методов класса ArrayList, придется ознакомиться еще с сотнями кусочков, прежде чем осознать свой путь к выходу :3
(Кстати о видеозаписях докладов. Приходите на джава-конференцию JBreak 2017, сможете набить мне морду за эти еретические мысли. Нет, я не докладчик по проблемам ООП, а вот какой-нибудь Бугаенко там точно будет)
