нужен ISP

возможно

а еще тебе надо избавиться от exec-ов в гейтвее

это я уже сделал

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

у меня есть Shell

(new Shell)->exec()

ты ж его не в гейтвее создаешь? а как зависимость передаешь?

разумеется

у него тоже есть интерфейс

ну вот интерфейс делать если у тебя сейчас только одна реализация... ну такое

лишняя работа

мне например обычно лень)

а у меня у всего только одна реализация

я всегда могу когда интерфейс стабилизируется сделать refactor -> extract interface

а у меня у всего только одна реализация

ну справедливости ради твоя задача решается спокойно на bash)

да

я всял простую задачу

и слои тебе тут не особо нужны

просто классы

можно даже без интерфейсов

интерфейсы офигенно нужны когда у тебя имеет смысл выделять границы между слоями/модулями

ну или для late binding

без интерфейсов приложение будет зависеть от гита

без интерфейсов приложение будет зависеть от гита

ну простой пример. Репозитории в доктрине

знаком же с ними?

ты делаешь для каждого репозитория интерфейс или тупо будешь работать с доктриной в одном классе и завязывать реализацию на него?

90% всех разработчиков не парятся и не выносят реализацию. Это можно сделать потом

собственно по этой причине я не пишу суффикс Interface у своих штук

я там выше как раз на эту тему скидывал видос

https://www.youtube.com/watch?v=ZsHMHukIlJY

видос о правильном именовании вещей. Эти суффиксы/префиксы не несут никакой полезной смысловой нагрузки и только засоряют систему. А когда у тебя нет этих суффиксов, то тебе без разницы интерфейс там или конкретный класс

а стало быть когда ты конкретный класс решишь заменить на интерфейс у тебя не будет с этим проблем.

хорошо

а вот модели

создание модели по ее ДТО

если они оба простые

нормально ли сделать статический конструктор у модели для этого?

тип fromDTO?

норм

да

в статике нет ничего плохого

все зло в статических пропертях потому что это все те же глобальные переменные

тогда такой вопрос

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

в смысле, нормально ли, что тест приложеня буде косвенно тестировать и модели?

unit test-ы это изолированные тесты

вот я дал приложению мок гита, который возвращает предопределенные DTO, приложение там что-то подумало, и выплюнуло DTO для представления

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

вот я дал приложению мок гита, который возвращает предопределенные DTO, приложение там что-то подумало, и выплюнуло DTO для представления

вообще может тебе не нужны эти все DTO и отдельные слои, у тебя в базе что-то храниться должно еще?

т.е. даже несмотря на то, что там внутри создаются другие классы, это все равно будет unit test

т.е. даже несмотря на то, что там внутри создаются другие классы, это все равно будет unit test

именно

нет никакой базы

гит-> приложение -> вьюха

ну и чуть-чуть конфига и пользовательского ввода

эм... то есть... твое приложение забирает DTO и тупо его возвращает наружу?

я к тому что откуда у тебя тогда необходимость в fromDTO?

так что по итогу остается приложению?

оно возвращает другое ДТО

хм....

а статический конструктор зачем тогда?

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

ну или TagList

эм.... $gitRepository->tags()

типа так TagList::fromDTO($git->getTags());

скорее так

типа так TagList::fromDTO($git->getTags());

ты по мойму сильно усложняешь

эм.... $gitRepository->tags()

в этом случае репозиторий возвращает готовую модель

мне кажется это неправильно, потому что репозиторий не должен знать про мою внутреннюю кухню

репозиторий это плагин

нет

репозиторий это git репозиторий

да

ну мол давай рассуждать не в терминах "паттернов"

именно он

а называть вещи своими именами

ты достаешь из "git репозитория" теги и коммиты

да

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

так

сами по себе теги в git это просто метки, они ничего не знают

дада

они помечают коммиты

ну вот у меня появляется GitRepo::getCommit(string $rev): Commit

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

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

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

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

Commit[]

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

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

ну

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

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

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

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

почему же?

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

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

почему?

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