то есть тебе нужна будет еще какая-то штука аля $gitLog->getCommitsBeetween($tag1, $tag2)

да. какой тип оно возвращает?

тупо массив строк?

Commit[]

массив коммитов

массив объектов

ну

никаких DTO пока-что нет

ну так я заебусь писать мок для этого метода

реализация же твоего git log может получит информацию в виде массивчика, и вместо того что бы мэпить его на dto можно прямо мэпить на сущности

ну так я заебусь писать мок для этого метода

почему же?

тест раздуется, мне надо будет создать реальные классы коммитов

у меня есть мысль что тебе вообще мокать ничего не надо

почему?

хотя ладно... в любом случае

замокать это не проблема

$tag1 = new Tag('v1.0'); $tag2 = new Tag('v1.1'); $log->getBetween($tag1, $tag2)->shouldReturn([ new Commit(), new Commit(), ]);

например

с другой стороны.... тебе проще будет написать сервис, который будет потом с этими коммитами что-то делать

и вместо моков передавать ему уже готовый список коммитов

а сервис, который будет координировать действия - его покрывать интеграционным тестом

там нет логики, он тупо делигирует задачи другим штукам

по итогу у нас необходимости что-то мокать вообще не будет

не все вещи надо покрывать юнит тестами

например если у тебя есть класс Application

который делает дела и тупо задает последовательность вызова других маленьких сервисов

в нем нет логики, тупо последовательность вызовов

и у тебя в тестах будет... просто продублирована реализация тестируемого кода при помощи моков

в таких тестах нет смысла

протестировать последовательност вызовов, не?

что произойдет если ты захочешь поменять последовательность вызовов?

тебе придется поправить и в тестах

и в итоге твои тесты не будут ничего проверять

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

а теста нет

риск налицо

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

open/close принцип. Декорирование.

расширяй функционал не внося изменений в имеющийся код

и ты будешь спасен)

ладно... я спатенькать, а то заседелся

пока

спасибо за беседу

There is another thing I'm struggling with.

DTO clearly violate the Law of Demeter

by exposing their internal structure

Сергей

В моём понимании так оно и есть. Можно сказать, "по определению".

Опять же моё понимание философии примерно такое: классы помогают уменьшить бардак в коде.

Но даже в "идеальном" коде всегда присутствуют string, int, и т.д.

Чем больше в коде "умных" классов, тем в теории меньше бардака. Однако в то же время из int делать некую умную структуру тоже фигово (например ультра-неэффективно).

вот и я не понимаю

A data transfer object (DTO[1][2]) is an object that carries data between processes.

this is from Wikipedia

the keyword is "processes" i guess

т.е. если у тебя это все в одном процессе живет, ДТО не нужны

The motivation for its use is that communication between processes is usually done resorting to remote interfaces (e.g. web services), where each call is an expensive operation.[2] Because the majority of the cost of each call is related to the round-trip time between the client and the server, one way of reducing the number of calls is to use an object (the DTO) that aggregates the data that would have been transferred by the several calls, but that is served by one call only.[2]

вощим понятно

Well, not really, I think. Let's say you use Memento pattern - at some point you're forced to serialize your "wise" object to some binary structure.

из одного класса в другой совать ДТО - это перегиб

Which, to my understaneing, is somehow close to DTO.

Именно. Моё понимание - DTO применимы когда "нас заставили".

Когда иначе - только хуже.

да

когда точно нет другого выхода

Передача данных по сети, например (like, protopuf lib - it's clearly DTO).

дада

Или передача между процессами.

да

Или когда у меня простигосподи ORM.

но явно не из одного класса в другой в пределах одного проекта

дадада

ну ОРМ это и есть передача данных между аппликухой и стораджем

Да, я бы не стал делать DTO где я могу нормально пользовать свой хороший "умный" объект.

ну ОРМ это и есть передача данных между аппликухой и стораджем

Я так искал примеры каких-то условно-правильных библиотек, с которыми можно общаться лишь примитивными типами данных.

Сегодня там сильно выше говорили про подход к анализу системы для её проектирования. Моё понимание этого дела - хорошо начинать с user stories, "как в итоге видит/понимает это всё конечный пользователь?". Задавать самому себе уточняющие вопросы - пока не будет казаться что "всё вроде ясно".

В итоге получается кучка требований.

ну вот как Сергей советует - строить сверху вниз

Вот существительные в этом списке - кандидаты на классы.

Глаголы - кандидаты на методы/API.

Мне оно так ничё помогает.

Можно сказать что это pull-проектирование (супротив push-проектирования). То есть мы проектируем лишь те функции/системы, которые дают полезный результат конечному пользователю.