$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-проектирования). То есть мы проектируем лишь те функции/системы, которые дают полезный результат конечному пользователю.

И да, оно тоже "сверху-вниз".

@f3ath есть апдейты кода?

(вроде в репо нп git не видно?)

не, я не пушил

да и не коммитил

пытаюсь построить свехну вниз

мне удалось избавиться от предствления вообще

и заодно от DTO)

мне кажется получается пока неплохо

блин

по LoD получается, что вообще объекты возвращать неправильно

никогда

как тогда LoD согласутеся с паттерном фабрика?

чето я не понимаю опять

Эээ кто в данном случае LoD?

law of demeter

Даётся мне, там говорится о том, что нехорошо лезть внутрь объекта, доставать его внутренние объекты, и что-то с ними делать.

Если мы так делаем - мы слишком дофига много знаем о внутреннем устройстве того несчастного объект.

Однако.

Логически та же фабрика не делится с нами внутренним состоянием - она генерирует внешние сущности для нас.

LoD это про то, что не должно быть такого object.foo().bar()

Ага.

аааа

я понял

Фабрика всякий раз генерирует _новый_ объект для нас, который не явлоется её внутренним состоянием.

дада

правильно

тогда ок

спасибо

чето я раньше был лучшего мнения о своих способностях к ООП

на деле как-то все грустно оказалось

Интересные темы поднимаешь. Я прямо хочу когда-то приехать в гости потрещать прямо на эту тему.