ты про юзкейс/юзерстори? Да, сначала это. Сначала надо определиться зачем и что нам надо. А сами тест кейсы это уже да, критерии приемки

да, я про это же

Нормально ли использовать hashmap (в php - массивы) в качестве DTO?

Что fetchRemote(string $remote) делает? (я слаб в php)

Что fetchRemote(string $remote) делает? (я слаб в php)

выполняет команду гитом

Мммм а результат куда-то возвращаестя, суть в том что оно менят состояние sandbox? (похоже на это)

ytn

меняет состояние внешней системы

результата нет

ясно тогда, спасибо

Читаю дальше

я так понимаю основных претензии к дизайну две - не тестируемо и нарушен SRP

попробую переделать

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

я так понимаю это будет Gateway PAttern

методы будут либо воздействовать на систему либо возвращать DTO

сука тяжело учиться

поделюсь и я своими соображениями

"большой плюс", что я php понимаю почти что никак :)

1) мне было сложновато уловить логику взаимосвязей классов - например Commit можно сконструировать "из sandbox", а так же получить из RevisionRange

угу

2) мне так же было не совсем ясно, чем собственно мы управляем? мне была бы наверное понятнее логика типа "есть sandbox и мы управляем им", что-то такое: class GitSandbox{ UpdateSandbox(revision); List<ChangelistDescription> ListRevisionsInRange(date1, date2); UpdateToTag(Tag); } class Tag { .... } class ChangelistDescription{ .... }

понял

спасибо

3) это уже чистая вкусовщина и опять же в каждом монастыре свои уставы ('best practices"), однако моя уверенность в том, что в коде важна читаемость - потому пропагандирую публичные методы (которые по сути API класса) выносить в самый верх, как наиболее интресные для читателя, а всякое приватное - прятать куда-то в подвал файла.

а у меня разве не так?

я вроде тому же правилу следовал

final class RevisionRange { private $from; private $to;

ну

это же перменные

их тоже в подвал?

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

получается, что она спользуется (например в конструкторе) выше, чем объявляется?

ок

я понял твою мысль

и в целом согласен

в С++ я настоятельно настаиваю всю реализацию (приватные методы и данные) в низ файла убирать, а публичной API - наверх

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

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

да, я не спорю, best practices они есть и им лучше следовать (ибо это то что читатель ожидает)

еще мне кажется что RevisionRange::__constructor и RevisionRange::between делают почти что одно и то же (или я упускаю опять же специфику)

так и есть

возможно, between избыточен здесь - мне симпатична сама идея хорошо именованного метода between, подчеркивающего поведение, одноко вместе с тем RevisionRange в моем представлении означает ровно то же.

блин как же тяжело

пока тесты напишешь, десять раз переделаешь все

зато YAGNI постигается на раз )

:)

где-то там же рядом концепция bit decay

Ща как применю TDD

Порекомендуйте книжки для джанго

https://docs.djangoproject.com/en/1.10/ Эту?

я так понимаю основных претензии к дизайну две - не тестируемо и нарушен SRP

с SRP 90% что у тебя будет нарушено, просто потому что сложно этот принцип не нарушать.

слишком много надо думать, хотя если подагоняться какое-то время будет чуть проще

Вот srp наверное последний принцип про который надо думать ?

Вот srp наверное последний принцип про который надо думать ?

не совсем. Все 5 принципов должны быть в балансе

иначе смысл теряется

вообще я все думаю засеть таки написать цикл статей свой... у меня сейчас куча идей уже записаны

SRP - только про зоны ответственности объектов, декомпозицию и кохижен. Про "делайте интерфейсы" ни слова O/C - тут интерфейсы уже полезны, но это разного рода стратегии, акторы и прочее... LSP - в целом тупо правила как правильно интерфейсы делать что бы не грустить когда делаешь O/C или ISP ISP - тут да, используй интерфейсы для того что бы изолировать зоны ответственности объекта когда тебе с точки зрения SRP выгоднее все держать в одном классе. Способ снижения связанности и только. Соблюдение ISP + SRP выводит баланс между coheasion и coupling DIP - изоляция модулей, опциональное, позволяет тебе просто между несколькими модулями инвертировать направление зависимости тем самым снизив связанность

а главное - все это опционально, не надо на этом зацикливться. Все это должно приносить пользу и в итоге ты просто где-то живешь с чуть большей связанность а где-то где все плохо можешь ее снизить используя эти принципы

SRP - только про зоны ответственности объектов, декомпозицию и кохижен. Про "делайте интерфейсы" ни слова O/C - тут интерфейсы уже полезны, но это разного рода стратегии, акторы и прочее... LSP - в целом тупо правила как правильно интерфейсы делать что бы не грустить когда делаешь O/C или ISP ISP - тут да, используй интерфейсы для того что бы изолировать зоны ответственности объекта когда тебе с точки зрения SRP выгоднее все держать в одном классе. Способ снижения связанности и только. Соблюдение ISP + SRP выводит баланс между coheasion и coupling DIP - изоляция модулей, опциональное, позволяет тебе просто между несколькими модулями инвертировать направление зависимости тем самым снизив связанность

??

мысли твои из симфони румы сюда направили)

ага)

ясно)

ты про юзкейс/юзерстори? Да, сначала это. Сначала надо определиться зачем и что нам надо. А сами тест кейсы это уже да, критерии приемки

куда гуглить, какие книжки читать об этом?

куда гуглить, какие книжки читать об этом?

к тому что "семь раз отмерь один отреж"?

что читать хз... тут подойдет любая штука на тему agile mindset, lean, user story и т.д. Например https://www.youtube.com/watch?v=6q5-cVeNjCE

годная штука по декомпозиции в виде юзер стори + acceptance criteria

по bdd конкретно есть следующие видосы: https://www.youtube.com/watch?v=2EM4itu7j7I

там 2 части, они вполне полезны

куда гуглить, какие книжки читать об этом?

Rspec book и cucumber book

@Enleur кстати вот Грег Янг тут обмолвился про save в репозитории https://www.infoq.com/presentations/8-lines-code-refactoring

"его там не должно было быть"

кстати, а почему вы пришли к orm?

вам не кажется что это очень плохая идея

если она делает что-то больше чем мапинг

@Enleur кстати вот Грег Янг тут обмолвился про save в репозитории https://www.infoq.com/presentations/8-lines-code-refactoring

а Серега что, говорил что норм?

да

а Серега что, говорил что норм?

ну он спрашивал ж

кстати, а почему вы пришли к orm?

быстрый старт

кстати, а почему вы пришли к orm?

а почему нет?)

и адский саппорт

у вас orm генерит sql запросы?

и адский саппорт

ни разу за 5 лет небыло жестких проблем с доктриной.

и адский саппорт

адский тюнинг перформанса

адский тюнинг перформанса

Могу немного про hibernate расказать.

ни разу за 5 лет небыло жестких проблем с доктриной.

со своей или в чужих проектах?)

и адский саппорт

если ты про SELECT запросы - да, львиную долю генерит ORM, он неплохо это делает для простых вещей. А для сложных набросать свой SQL просто проще

Могу немного про hibernate расказать.

И про то что, что мы в итоге скатились в нативные запросы.

со своей или в чужих проектах?)

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

И про то что, что мы в итоге скатились в нативные запросы.

тебе скинуть точку зрения авторов доктрины на то как надо юзать доктрину что бы все было ок?

если коротко - ORM нужны для обработки маленьких бизнес транзакций. Если тебе нужны репорты - юзай SQL

примерно вот так делаем запросы public function getInvoiceByHashAndUserId($hash, $userId) { return $this->createQueryBuilder('i') ->select('i, o, u') ->leftJoin('i.order', 'o') ->leftJoin('o.user', 'u') ->where('i.hash = :hash') ->andWhere('u.id = :userId') ->setParameter('userId', $userId) ->setParameter('hash', $hash) ->getQuery() ->getOneOrNullResult(); }

хм, в целом выглядит довольно неплохо

примерно вот так делаем запросы public function getInvoiceByHashAndUserId($hash, $userId) { return $this->createQueryBuilder('i') ->select('i, o, u') ->leftJoin('i.order', 'o') ->leftJoin('o.user', 'u') ->where('i.hash = :hash') ->andWhere('u.id = :userId') ->setParameter('userId', $userId) ->setParameter('hash', $hash) ->getQuery() ->getOneOrNullResult(); }

спецификации не крутил?

хм, в целом выглядит довольно неплохо

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

хм, в целом выглядит довольно неплохо

местами где надо забиваем вообще на ORM и юзаем только удобный querybuilder, по сути тот же jOOQ)

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

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