ООП иль процедурка?

Привет!

Законспектировал себе Веста.

Предлагаю выбрать точку опоры для исследования = физиология обычного человека (ОЧ).

Ограничения вычислительных способностей ОЧ вызвало появление способов программирования. Как пишут отцы: сначала прямо 0 и 1, затем придумали ассемблер, затем языки выше уровнем, затем процедурные, затем ООП.

Это упрощённое описание развития ЯП отражает увеличение сложностей задач, которые решали люди при помощи компьютера.

Можно и сейчас писать всё на ассемблере. И есть такие выдающиеся. А ОЧ не может, ему трудно.

О чём и рассказывает уважаемый Егор Бугаенко - в его жизни пришло время, когда он стал браться за задачи, которые процедурным стилем решались перенапряжением его умственных способностей, что привело к потере удовольствия от программирования. А Егор (как и мы) любит и хочет программировать с удовольствием. И Егор нашёл этот способ.

И я ему признателен за это, потому что, как ОЧ, я столкнулся с ситуациями, когда дня три с упоением программируешь процедурно, а потом бац! И собственный код становится непонятным, плохим. И начинаешь заново, огульно, программировать процедурно. И опять на день 4-5 свой код становится непонятным, плохим.

А тут Егор: MAINTAINABLE = наше всё.

И я начал учиться объектной декомпозиции – моделировать «тупых» надёжных исполнителей. Классы я редко использую. Своих исполнителей я «упаковываю» матрёшкой. Функции пишу простыми и короткими, чтобы, увидев их через месяц-два, у меня (да и ни у кого) не возникало желания их «упростить».

И эти короткие методы помогли понять Егора: «Кто не пишет юнит-тесты, тот дурак».

Как в рукопашном – быстрые и сильные идут в ММА, а обычные к Кадочникову. Так и в программировании – талантливые кодируют так, что ОЧ не понимает их код. А ОЧ используют ООП от Веста, благодаря Бугаенко.

Вы спрашиваете: «логика поведения каждого обьекта собрана в одном месте? Или она как обычно размыта между разными обьектами?»
Объект решает, что ему делать. Он короток, он понятен, он инкапуслирован. Вначале кажется парадоксом, но ограничения ОЧ вынуждают решать сложные задачи, используя тупых (реально тупее некуда) исполнителей. А лень кодировать даже простых исполнителей вынудит Вас использовать код повторно - а это резко увеличивает производительность (+ не надо писать юнит тесты) нашего труда и кайф от программирования.
Набрал “тупых” и пусть они сами решают проблему. Это реально прикольно, когда программа делает, то что ты хотел, а начинаешь её пошагово отлаживать и не можешь понять: Куда? Зачем? Почему?  - о чём и писал Давид «Думать как компьютер = дурная привычка в проектах чуть сложнее простого.»

В физическом мире Вы можете нанять исполнителя, который закупит стройматериалы и сделает ремонт, а программируя это, если Вы ОЧ и любите программировать с удовольствием, Вам придётся придумать или использовать максимально тупых и неумелых исполнителей.
Матрёшку читать снизу вверх:
…
Т.д.
Т.п.
Раствор_Положи
Раствор_Мешай
Лишнее_Отрежь
Плитку_Посчитай
Материал_подними
Материал_привези
Материал_выбери
Продавца_найти
Магазин_Где
Деньги
Замеры

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

Хорошее самочувствие Ваш верный ориентир.