то есть время стоит исключить, когда смотришь насколько кохизив объект?
Я к этому склоняюсь 🤔

В итоге все эти «маленькие самодостаточные штуки» неизбежно стекаются в те самые utils/handlers/common/core, и уже там их все и не любят )

Или просто на cohesion надо смотреть не только с точки зрения кода. Если связь между кусочками стейта объекта происходит не в коде, а в голове человека (который что-то знает про бизнес-логику), который смотрит на этот стейт - это тоже считается?

Ну у меня обычно если я хочу штуки типа даты обновления форсить они в инфраструктуре - типа метаданных

На кого рассчитаны подобные сообщения в русскоязычном чате?

Они тратят карточку мобильную и им все равно во сколько чатов слать

Карточка все равно будет забанена. затраты компа на еще один запрос - миллионные доли бакса. Прибыль ожидаемая - центы. Выгодно. Вот и шлют везде где могут. Даже в русских чатиках есть некоторый % англоговорящих.

Чтобы как можно больше функций в предметной области были чистыми, если у тебя внутри функции "берём текущее время", функция не является чистой. Это не смертельно, но если есть хороший способ сделать функцию чистой это надо делать

Ну это он и говорит. Но мой вопрос в том насколько эта независимость от дейта нужна?

иногда имеет смысл, тут уже говорили про платежи

видел доклад Солнцева (автор Селенида), что ловили хейзенбаг тесты, которые иногда падали, а на время критичный функционал завязан...

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

решением было: использовать не системное время, а относительнео время в Джаве

Как минимум тестить эту функцию будет просто, снижение когнитивный нагрузки всей кодовой базы. Представьте у вас 80% кодовой базы это чистые функции. Если дата время там реально нужны можно просто передать clock

ну да кстати, иногда это очень важно... все ваяют свои костыли с clock или берут что-то типа Карбона, где из коробки это есть (вроде как видел в упоминании фич)

потому что "сейчас" в тестах — очень относительная штука

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

В целом рекомендую почитать чего на тему functional core imperative shell

вот хорошее на эту тему

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

простой пример: тик цены в сделках в биржевых системах

Сложна, непонятно о какой яме идёт разговор

ааа, да есть в моем выражении такие проблемы, по сути вы получается что система существует, по ее snapshot в runtime, а не в runtime по ее uptime. Вот этот разрыв между snapshot и uptime и есть глубина ямы. В некоторых системах он ближе к единице (отношение слепка-snapshot отчета от запаздывания наполнения и все отлично, напримерd системах управленческого учета). А вот в "живых" типа систем обработки транзакций сделок 24/7 или систем производства он отличен от единицы, то есть меньшее ее, и начинаются я проблемы в оценке, и чем ближе к нулю, тем больше проблем.

Это вы так описали ГЭП в eventual consistency?