https://gist.github.com/f3ath/686fcb4162ffa47fb6823cd316e13428

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

как ее разбить на части?

метод в 30 строк

это собственно моя основная логика приложения

центральный if смущает

$url и $revisions всегда ходят парой

выделить их в объект?

RevisionRange

Смотрю

GitGateway получается херовый

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

ReleaseNotes получает имя тага и печатает комментарии к коммиту?

(или вообще ко всем таженым коммитам, если не указали)

?

печатает все новые коммиты в теге

по сравнению с прошлым тегом

http://keepachangelog.com/en/0.3.0/

элемент changelog'а печатает

а

можно адааптер замутить

враппер вернее

к GitGateway

который будет создавать сложную херню типа RevisionRange

тогда и URL и набор коммитов получаются свойствами RevisionRange

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

а бывает фасад к одному классу?

Почему бы и нет.

Класс который преобразует низкоуровневый интерфейс во что-то более высокоуровневое. Не вижу греха.

тогда это фасад наверно

фасад над GitGateway

понимашь, что я имею в виду?

о

я начинаю сходить с ума )

почитал http://keepachangelog.com/en/0.3.0/ и картина как-то проясняется вроде

итого

ты хочешь тулзу, которая читает логи git репо и каким-то способом их парсит и куда-то красиво (?) печатает

да

в консоль

ок

теперь я понимаю почему ReleaseNotes на самом деле один из главных действующих лиц здесь

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

это getCommitDetails скорее

readCommitDetails() мне бы помогло

да, так я бы меньше плутал

объект GitGateway настраивается на конкретное репо и потом все данные берет из него (типа "переклчиться ну другое репо" - так не планируется / не работает)

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

именно так

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

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

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

и она большая

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

нууу....

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

:)

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

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

ну да

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

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

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

одноко

if меня бесит

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

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

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

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

мммммм

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

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

ТИПА

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

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

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

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

changelog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но попробую)

Ж)

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