еще раз

иначе нет никакого смысла в разделении на слои

B это не UI

B это не UI

тогда я запутался

это интерфейс доступа к гиту, я из него читаю

ааа

имплементация может быть разная

тогда тебе нужна инверсия зависимости)

либо консольный гит

и тогда все будет хорошо)

либо через сеть

ну я и организую ее интерфейсом

и приложние и гейтвей к гиту - оба зависят от интерфейся

а

интерфейс описывает методы, которые должны возвращать ДТОшки

https://gist.github.com/fesor/4e56f536448463d4e5f4939287b42f6d

да, правильно у тебя в коде

обрати внимание что Infrastructure зависит от App а не наоборот

ну мол ты науровне слоя приложения сказал "у меня должна быть штука которая вернет мне мой DTO"

и тогда DTO точно относится к слою приложения без всяких оговорок

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

и твое приложение останется изолированным от инфраструктуры

точно так же собственно и с UI

понял

да

так согласен

аргументируй

Аргументирую. Git - сервис, существующий за пределами нашего влияния, и изменить его поведение затруднительно. Он _уже_ предоставляет сервис, изменить/исправить который мы де-факто не можем. Всякое наше приложение в любых раскладах будет использовать существующие возможности Git. Создавая класс, организующий общение с Git, есть смысл определить поведение (созданием интерфейсного класса) - с набором методов, которые позволят нашему (дальнейшему) приложению общаться с Git. Интерфейс оный что-то должен будет "делать", и иногда "возвращать". Вот в этом месте неминуемо нам тут же необходимо договориться/пообещать, что именни и в какой форме будет этим нашим программным интерфейсом (фасадом к "настоящему" Git) возвращаться. Здесь естественным образом возникает определение структур данных, в терминах которых произойдёт общение с Git. Далее, мы реализуем имплементапию этого интерфеиса - получаем git communication library. Далее (хотя можем ирпараллельно, если интенфейс уже определён) мы пишем уже "клиентское приложение", которое интенфейсом пользуется.

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

Аргументирую. Git - сервис, существующий за пределами нашего влияния, и изменить его поведение затруднительно. Он _уже_ предоставляет сервис, изменить/исправить который мы де-факто не можем. Всякое наше приложение в любых раскладах будет использовать существующие возможности Git. Создавая класс, организующий общение с Git, есть смысл определить поведение (созданием интерфейсного класса) - с набором методов, которые позволят нашему (дальнейшему) приложению общаться с Git. Интерфейс оный что-то должен будет "делать", и иногда "возвращать". Вот в этом месте неминуемо нам тут же необходимо договориться/пообещать, что именни и в какой форме будет этим нашим программным интерфейсом (фасадом к "настоящему" Git) возвращаться. Здесь естественным образом возникает определение структур данных, в терминах которых произойдёт общение с Git. Далее, мы реализуем имплементапию этого интерфеиса - получаем git communication library. Далее (хотя можем ирпараллельно, если интенфейс уже определён) мы пишем уже "клиентское приложение", которое интенфейсом пользуется.

мы уже выяснили что под "интерфейсом" в этой дискуссии я сдуру подумал что про UI речь идет

я выше привел ссылку на gist - глянь, совпадает с твоим пониманием проблемы?

Гм

мне кажется у меня прояснились некоторые вещи

вся соль в изоляции и декомпозиции

ну то есть ты можешь просто на бумажке рисовать схемки из операций... что тебе надо и т.д

вся соль в изоляции и декомпозиции

я фразы типа этой ежедневно слушаю через ютуб по дороге на работу

и обратно

тип "сначала надо то-то то-то"

потом "то-то то-то"

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

только понимания не сильно добавляется

ну мол "нужна хрань которая из git-а забирает лог"

потом "нужна хрень которая из лога отфильтрует что-то"

ну и т.д

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

желательно что-то что ты раньше не делал

мне очень интересно

я хочу ее довести до нормальной реализации

я к тому что ты уже код написал и упражнение будет смазанным)

а

хотя кто его знает

так я как написал так и сотру

я уже раза четыре заново начинал

составь список "как это должно примерно работать". Не структуру классов, а тупо последовательность действий примерную. Атомарные операции отдельные которые нужно провернуть

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

главное понимать что надо делать

не придумавый имена операциям, не придумывай слоев

тупо список действий))

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

да

но его не пиши

вообще ничего про UI в этот список пока не пиши

тебе сейчас надо приложение само по себе описать как работает

юзер стори + критерии приемки

да мне бы импрементацию гита описать сначала

ну вот я об этом и говорю

только приложение

без UI

а

т.е. сверху вниз строить структуру

причем пиши абстрактно

именно

сначала с пустыми интерфейсвами

сверху вниз

сначала с пустыми интерфейсвами

ээээм.... никакого кода или сущностей

ну например... задача - надо сделать програмку которая формирует рейтинг коммитеров

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

она уже сложная что пиздец

как ее реализовать?

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

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

да

ну вот, у тебя уже есть два сервиса)

по сути сервис который сделает git log tag1..tag2

и нормализует структурку возможно минимально

и другая хрень которая на основе этой истории что-то сделает

еще нужна будет хрень которая будет уметь выполнять команды

что бы не через exec везде и всюду

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

определить последний

а тупо $this->process->run("");

или указанный

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

ну вот, еще класс

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

то есть мне получается не нужен один интерфейс на GitGateway, а нужно ISP на каждую операцию?

если тебе надо сделать работу, и есть более одног оспособа это сделать, лучше вынести эту операцию в отдельную хрень

то есть мне получается не нужен один интерфейс на GitGateway, а нужно ISP на каждую операцию?

почему один?

может быть и 10

кто тебя знает

класс может быть один