🐴

именно так

Sergei

ReleaseNotes решает понятную (мне теперь) задачу - ему дают указатель на интерфейс Gitgateway, из которого он хитро парсит commit descriptons - вроде все вполне рукопожатно в этом на мой взгляд.

Sergei

мммм единственное смущение - ReleaseNotes имеет внутренние данные ($git) которые используются ровно в одной функции.

Sergei

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

🐴

и она большая

Sergei

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

🐴

нууу....

🐴

можно вообще все приложение заменить баш-скриптом

Sergei

:)

Sergei

с этим не поспорить, конечно.

Sergei

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

🐴

ну да

🐴

я ж в ООП играюсь тут

🐴

прототип у меня работает - один файл из 40 строчек

Sergei

в общем я перечитал код еще раз - мне сложно к чему-то всерьез придарться. даже сложно поддержать твоё замечание про то что метод слишком длинный - по моим ощущениям 30 строк делающих более-менее монолитную активность это вполне еще Ок.

Sergei

одноко

🐴

if меня бесит

🐴

я щас превратил его вот во что

🐴

https://gist.github.com/f3ath/13592b4368c50ba63a0e315accde22e6

Sergei

если предположить, что описание каждого коммита имеет сложную структуру, то есть хороший смысл замутить patter interpretator

🐴

но классы Release и SubsequentRelease весьма уродливы

Sergei

мммммм

Sergei

это кажется ход как раз в ту сторону о которой я вот выше писал

🐴

ну типа полиморфизм вместо ифа

🐴

ТИПА

🐴

и теперь $git путешествует по всем внутренним классам

Sergei

как я понимаю ты планируешь преобразовать некий в общем plain text в красивую стуркутру типа какой-то_комментарий_к_коммиту_с_разметкой => логический_блок_описания1, логический_блок_описания2, логический_блок_описания3 ... ?

🐴

и тстировать все равно сложно

🐴

мне нужно в точности то, что описано по ссылке

🐴

changelog

🐴

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

🐴

у меня щас ООП ради ООП

Sergei

то что $git пополз по городам и весям - может быть не сильно хорошо. альтернативой могло бы быть $revisionsToIncludeInReport = $this->$git->GetCommits(rev_begin, rev_end); $release = new ReleaseDescription($revisionsToIncludeInReport); $release->printHeader($printer); $release->printChanges($printer);

Sergei

то есть я имею тут ввиду что ReleaseNotes решает, какие ревизии(коммиты) должны быть включены в собственно release notes (что само по себе кажется даже разумным), получает их описания из $git (который уже никому другому не дает), и потом создает объект ReleaseDescription который строится получая на вход уже не $git а набор обектов-описаний диапазона ревизий.

🐴

ReleaseDescription тогда становится довольно тупым

Sergei

таким образом мы попрятали $git внутри одного класса и тем самым даже соблюли single responsibility

Sergei

ReleaseDescription тогда становится довольно тупым

согласен отчасти

🐴

я шас по-другому их попробую разделить

🐴

ReleaseNotes херовое название

🐴

оно вводит в заблужение

Sergei

его ответсвенность - уметь по запросу извне (по тэгу) выбрать нужные коммиты из git. при это другая система уже будет из этих запростов делать какой-то красивый текст.

🐴

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

🐴

либо я заноняюсь уже

🐴

но попробую)

Sergei

Ж)

Sergei

я спать - у меня завтра поездка в сторону Sierra Nevada с утра.

🐴

споки