Ну приведите пример объекта-глагола.
Глагол – это обычно процедура или функция, а не объект.
Да, это будет система клеточек и сторон с правилами взаимодействия (поведение системы с бизнес-логикой вращения). Но нам где-то нужно будет хранить текущее состояние этой системы. Карту позиций и углов каждой клетки. Её можно хранить или в отдельной переменной и менять его процедурно или функционально, или вместе с правилами объединить в объект "кубик".skynin писал(а): ↑2019.08.17, 17:10 ООП не навязывает способ декомпозиции - как при моделировании, так и при написании кода
Кубик рубика можно описать как объект с поведением и состоянием, а можно описать клеточки и стороны и правила их взаимодействия, чтобы сэмулировать "кубик рубика"
Как удобнее - общего правила нет.
Но точно, еще раз - сами ООП не обязывают описывать "кубик рубика" как объект, ни на уровне модели, ни на уровне кода
Это не телепатирование, а ответ на ваш перл, что в Go нет классов и объектов и нет ни одной ОО строки.
Но у того и у того есть поведение и инкапсуляция. Так что в этом плане разницы нет.
Тогда называйте, какие это проблемы, а не просто философствуйте. И связаны ли они с неверным разделением контекстов.
Всего лишь перенос логики из внешнего ЯП проекта во внутренний ЯП базы данных. Для снижения накладных расходов на мэппинг и повышения консистентности в пределах одной базы. И даже с этим можно работать объектно в виде DB Speaking объектов с инкапсулированной логикой.
Могу подсказать. Это все проекты, решившие стать микросервисными.
На старте было монолитом на хранимках и триггерах. Что же потом происходит? Происходит разделение на подпроекты с отдельными базами. Это ведёт к отказу от предыдущих хранимок и нативной консистентности, так как в распределённой системе они абсолютно бесполезны. И логика из многих хранимок переходит в код.
Чтобы сохранять весь такой самостоятельный объект в персистентное хранилище.