Здравствуйте, Wolverrum, Вы писали:
W>И чо?
W>Индусы код не поймут?
Да.
W>Система работать не будет?
W>Цена поддержки многократно вырастет?
Да.
W>Чувству прекрасного будет нанесен невосполнимый урон?
Да.

Вы поймите, ООП решает вполне конкретные задачи. Это же инженерная дисциплина.
И всякие полезные принципы, типа SRP, они для того, чтобы помочь людям добиться от ООП той пользы, которая в нём потенциально есть.
Понимаете? С точки зрения функциональных требований все парадигмы совершенно одинаковы — см. тезис Чёрча. То есть в принципе нет такой программы, которую можно было бы написать на ФП, но нельзя на ООП — как и наоборот.
Отличия — только в нефункциональных требованиях. Например, в том, сколько стоит отладка (т.е. доказательство корректности, хотя бы и нестрогое) и внесение изменений. Или в том, насколько эффективный код получается в результате.
Ну так вот понятность кода напрямую влияет на стоимость его поддержки.
Возможность изолировать эффекты локальных изменений — тоже.
Именно ради неё Кей вводил эти "чёрные ящики", а не потому, что они как-то особенно подходят к устройству мозга.
Как только мы отказываемся от преимуществ этой изоляции, ООП превращается в культ карго — написание кода ради самого кода.
Часто именно такая ерунда получается в т.н. рич-модели — это где элементы предметной области искусственно наделяются поведением. Получаем лишний код, который нужно писать, и нужно исполнять.
С точки зрения классического, незамутнённого ООП, вызов метода transaction.getAmount() — это обращение к чёрному ящику. Мы не имеем права интересоваться, как устроен этот код. У нас нет другого способа узнать, на какой счёт переводятся деньги, не вызвав метод transaction.getAccId().
Так что если у нас есть список транзакций, мы обязаны честно полностью его проходить и выполнять все обращения:

foreach(var t in allTransactions)
  if (t.getAccId() == accId)
    sum += t.getAmount();

Только отказ от "чёрной ящиковости" позволяет нам делать хитрые преобразования — например, строить индексы в СУБД.

S>>То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.
W>Выделенное плохо?
Выделенное очень хорошо.
W>Подчеркнутое обязательно?
Крайне желательно.
>>anemic model:
>>"Logic cannot be implemented in a truly object-oriented way"
Здесь truly имеет саркастический оттенок. Да, с точки зрения ООПГМ-нутых анемик — это плохо, потому что в нём бухгалтерские счета внезапно перестают быть объектами, а в ущербной ментальной модели ООПГМ-нутого все сущности предметной области обязаны быть объектами. Именно это пишут в говноучебниках.
А с точки зрения профессионала анемик ничуть не ограничивает применение ООП — просто в нём объектами становятся элементы решения, а не задачи.
Вместо того, чтобы вводить объекты для чисел и уравнений, мы вводим объект EquationSolver.