не соглашусь с вами. и тут не понятно тоже аргументы почему ООП устарело. Тут больше от человека зависит что именно и как дизайнит проекты. Но какие альтернативы вы можете предложит вместо ООП?

а про то что вы говорите не читать книжку или там чтобы начинающий смог только решать задачки

это просто порождает еще одного говнокодера который не будеть знать основы и теорию. И просто не сможет написать более чистый код или придумать дизайн. Просто будет весь свой проект  в одном классе, со 5-6 тыс строками кода? самое главное же решать задачу

так же человек должен будет не только с нуля писать. А в основном работать с имеющим проектам, а там везде ООП. И на собеседование у него тоже будут требовать знании этих основ. Ему что потом ответить ? мне в телеге сказали что ООП устарел я и забил. А на ответ почему автор сам сказал что вопрос сложный?

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

Образовательные холивары самые сложные, один человек говорит, за 2 месяца язык разработки выучил и применяет, а другой уже 2 года учится где нить и не понимает. А факторов куча:
-Наличие хорошей памяти
-Скилы к обучению
-Периодичность и длительность занятий
-Итд

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

сколько раз не посмотрел, у всех все через практику, и мало кто задавался вопросом а нафига и почему именно так

и получаются проект гавнокод

Возможно имелось ввиду про ООП которое было спроектировано именно в Java, а не оригинальная идея ООП Алана Кая где нету наследования которое порождает проблемы, и связь между обьектами должна происходит через сообщения. Например новые языки программирование как Котлин по default делают свои классы закрытыми, в языке Go вроде как тоже есть другой подход там уже не могу точно сказать.

у каждого языка есть свои нюансы. Но тут же именно речь идет о Java. И модульность никто не отменял для таких кейсов)

Прочитал Философия Java 4 раза. Читал 5 лет назад.
Когда прочитал в первый раз, понял 10-20 % из книги.
Второй раз через некоторое время прочитал, понял только 30 %.
В третьи раз уже 70 %.
В четвертый уже 100 %.
И все это с промежутками и с набором боевого опыта.
Мне кажется эту книгу не реально понять новичку с первого раза.
Поэтому не стоит расстраиваться когда что то не понятно.
Но книга отличная. Дает понимание как язык устроен изнутри.
Но тяжелая книга для новичков.

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

Всем привет. Такая ситуация:
Разрабатываем систему документооборота на Spring boot. Использовали StateMachine. Но теперь прилетело требование чтобы маршрут документооборота был с возможность изменения админом. Как пример, если раньше документ должен был пройти через 3-ех человек по прямой линии, теперь из 7 и уже не по прямой, а с ответвлениями. Т.е. система должна быть гибкой по маршрутам.
Вопросы:
1. StateMachine уже не подходит?
2. Подходит ли BPMN? Camunda например
3. Есть другие варианты?

Проект говнокод получается изза того, что нет нормальных процессов код-ревью и прочего

Никто не пишет идеальный код прочитав книжку по жаве

А тем более книжку про ООП

Я и не говорю что писать совсем идеальный код) ну хоть глаза не будут резать , а так как до этого говорили , книжку можно читать не один раз, и с каждым разом всё лучше писать

И вообще я не понимаю вопроса: какая альтернатива ООП? Альтернатива ООП — это хорошо читаемый и поддерживаемый код, не важно на каком языке и в какой парадигме

Потому что ООП точно не равно «хороший код»

Например, DI который в Спринге — я не считаю ООП