Я сказал про аттрибуты, но не сказал про методы. У структур как правило методов все же нет, не?

Ничего плохого, держать по разному можно просто.

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

Такой подход у Uncle Bob называется mutability segregation вроде

звучит как скала

Да те Серег, терь везде скала мерещиться будет :D

Если Стейт не меняем, то и методы это полиморфные функции, где класс выступает в роли модуля из процедурности

не, ну вот строчка . "Только в момент, когда мутабельность таки нужна, можно не изголяться с монадами а просто сделать мутабельно." это прям отличие скалы от чисто фпшных языков

Не забываем об интерфейсах

Ну да, так и есть

То есть о хидерах как в с++

Лол

Процедурщина

Не, ты не так понял

Класс - просто модуль (как ты выразился), если не имплементирует контракт (такой класс реально бесполезен). Имплементируя контракт (интерфейс), класс собирает эти ваши функции в конкретное реюзабельное решение проблемы, описанной контрактом. Если все сделано четко по LSP, то класс это все же нечто большее чем просто модуль, или сборник функций.

На процедурщину больше смахивает как раз спринг с autowired, где классы (сервисы) - это сборники процедур, а autowired инъекции - это намертво прибитые к этим "модулям" зависимости на другие "модули"

Но ты сам сказал - стейта нет, класс это набор атрибутов, а функции класса продиктованы неким внешним файликов в определенной структуре. Как по мне, так просто модуль с хидером описывающим набор функций и некой структурой

Ну так все можно утрировать. И я не говорил что стейта - нет, я говорил что юзать атрибуты в качестве стейта - занятие на крайний случай.

Кроме того - как насчет клиента? Если клиентские объекты оперирует контрактами, а не конкретиками (а они должны всегда оперировать контрактами вместо конкретик, по DIP), то такие объекты можно реюзать и композировать максимально гибко. Сишный include такого не дает, если ты к этому клонишь.

Ну не совсем, хидеры это вполне себе контракт

Послушал немного Егора Бугаенко в Ютубе. Мне эти разговоры о структуре классов кажутся не о главном. Не сложно предложить акцент на какой-нибудь особенности типа «Давайте не пользоваться сетерами и гетерами потому что <убедительные аргументы>». Сложнее при этом построить какую-то архитектуру, в которой потом не запутаешься. Когда у тебя вместо трёх портянок три тысячи "микроклассов", то возникает гора вариантов как их упорядочивать, как их именовать, и всё это превращается в разновидность хардкода. Есть тип партяночного хардкода, когда ничего не найти в пределах файла, а тут ничего не найти в пределах кучи микроклассов, декораторов на декораторы.

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

Мне это его возмущение, с одной стороны, кажется оправданым, сам возмущаюсь каждый день. Но, с другой стороны, всё же кажется незавершённым. Его предложения ничего по большому счёту не меняют и видимо это какой-то другой вопрос: чем сложнее код, чем сложнее система, тем больше в ней тендений распада, проблем поротливости и усточивости. Это очень не слабая тема. Сомтинг лайк тэт.