Read models naming

Проверенные VDS на SSD в Европе от $4 и России: Датацентр №1 от 199руб

Тема в разделе "Вопросы по теории программирования", создана пользователем Adelf, 31 окт 2017.

  1. Вурдалак

    Вурдалак Newbie

    Сообщения:
    6.025
    Ваш город:
    Russia, Moscow
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    Я бы больше хотел final properties как в Java, но в 99% (по крайней мере, в моём случае) эти фичи бы использовались одинаково.
     
  2. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    отвлекаясь от терминологии, речь о том, что для соответствия интерфейсу объекту нужно реализовать его методы,
    а в golang можно задать и структуру данных https://tour.golang.org/methods/11

    что касается терминологии, в документации по TypeScript прямо написано, что он реализует "duck typing", а в golang - про implicit implementation

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

    я подразумеваю наличие PHPDoc

    собственно, вопрос сводится к тому, насколько часто ты работаешь с такими коллекциями, при работе с которыми нужно помнить структуру в разных местах, а @return Foo[]|Collection не хватает
     
    Последнее редактирование: 14 ноя 2017
  3. Adelf

    Adelf Laravel&PhpStorm Команда форума

    Сообщения:
    3.124
    Ваш город:
    Казань
    Address:
    Kazan, Russia
    Country:
    Location on Map:
    Засорили тему :) Я тут хотел вопрос задать. Немного в догонку. А как юнит-тестить write модели? Результат проверять как? анализируя только events и все?

    Ну вот в С# прям сильно удобно работать с коллекциями. Linq. В яве тоже стримы ввели. Не просто так. Частенько такое пригождается. Мы просто привыкли к foreach. Но и там надо кастить переменные к типу. тут важно не столько "помнить структуру", а для какого-то поля - возможность быстро найти ВСЕ места где оно юзается. Сильно ускоряет рефакторинги. А с массивами везде приходится phpDoc или типизировать аргументы колбэков. Не совсем удобно.
     
  4. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    интеграционный тест сделай с предварительной инициализацией базы, и не мучайся
     
  5. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    ты раздели вопросы: foreach, кастинг к типу, структура, рефакторинг
    для читаемости и рефакторинга нет большой разницы указывать ли типизацию в коде или в PHPDoc, если есть желание ее указывать,
    другое дело, что ты не указываешь, когда можно этого не делать, но защищать программиста от самого себя - это так себе цель

    знаешь, к чему привела строгая типизация в джаве? кодеры не проверяют работу своего кода, скомпилировалось - значит, правильно
     
    Последнее редактирование: 14 ноя 2017
  6. Вурдалак

    Вурдалак Newbie

    Сообщения:
    6.025
    Ваш город:
    Russia, Moscow
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    @grigori санкции — это польза, рабство — это свобода, удобство — это недостаток.
     
  7. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    не понимаю
    это аргумент против какого моего тезиса?
     
  8. Adelf

    Adelf Laravel&PhpStorm Команда форума

    Сообщения:
    3.124
    Ваш город:
    Казань
    Address:
    Kazan, Russia
    Country:
    Location on Map:
    Думаю, против :)
    я уже говорил что для нормальной скорости рефакторинга разница есть. Да и не только рефакторинга... я юзаю Find usages несколько раз в день.
     
  9. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    нет, я не оспариваю потребность в типизации элементов коллекций - это желание очевидное, я думаю о других вопросах:
    * в каких именно ситуациях нельзя компенсировать недостаток с помощью PHPDoc
    * нет ли в этом поиска идеала "Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича"
    * как решить задачу
    * есть ли у дженериков цена компиляции
     
    Последнее редактирование: 14 ноя 2017
  10. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    в питоне, раби и golang дженериков нет - в питоне только статическая проверка по комментам в mypy,
    задача обеспечения полиморфизма с типизацией решается через duck typing некоторого вида, что совсем не решает задачи @Adelf
     
    Последнее редактирование: 14 ноя 2017
  11. Adelf

    Adelf Laravel&PhpStorm Команда форума

    Сообщения:
    3.124
    Ваш город:
    Казань
    Address:
    Kazan, Russia
    Country:
    Location on Map:
    да там даже интерфейсов нет. да я не мечтаю даже о нормальных дженериках в PHP. Чую я, это весьма непросто для скриптовых языков. где-то наверняка будут просадки по производительности. все эти ко и контра-вариантности...
    Хотя... с jit-компиляцией всякой... но все равно работы там туча туч
     
  12. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    в общем, как писал Льюис Керрол,
     
  13. Вурдалак

    Вурдалак Newbie

    Сообщения:
    6.025
    Ваш город:
    Russia, Moscow
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    Если у тебя event sourced модель (не в плане персистности, а в плане внутренного устройства), то этого должно быть достаточно.

    Но если ты используешь, например, Behat, то там скорее всего сценарии будут совпадать с теми, что ты описываешь в unit-тесте и необходимость в точечном unit-тесте как-то отпадает. То есть, можно действительно заодно проверить взаимодействие с инфраструктурой.
     
  14. fixxxer

    fixxxer К.О. Партнер клуба

    Сообщения:
    12.446
    Ваш город:
    Moscow, Russia
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    А получается с BDD only следовать принципу test first? Сценарии-то разной сложности бывают, могут затрагивать не только одну write model.
     
  15. Вурдалак

    Вурдалак Newbie

    Сообщения:
    6.025
    Ваш город:
    Russia, Moscow
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    В BDD как раз нет «test first», там «specification first», а этому следовать получается уже более-менее.
    Ведь тут главное — раскрыть команды и события, причём совсем необязательно писать сначала сценарии, там есть блоки свободного текста, где ты можешь писать вообще что угодно. Затрагивать несколько сущностей, конечно, может, но это не мешает описать логику и сценарии сначала для одной. Да и по опыту спецификации в основном вертятся вокруг одной сущности.

    С PHPUnit у меня всегда проблема в том, что там больше всё-таки тест: там нужно использовать ещё несуществующий класс, методы и события, либо бегать туда-сюда, что неудобно. Я ещё толком не знаю как назвать команды и события, буду сначала их создавать, чтобы описать в PHPUnit-тесте, а потом тут же переписывать, потому что понял, что они неудачные. В результате я просто буду писать код в модели, чтобы понять, норм ли это, и в итоге всё сводится к «test last».

    Я не против PHPUnit, и использую его, но TDD нет. Behat же приучает именно к другому типу разработки и тестирование с ним становится лишь следствием, что уже выглядит естественно. TDD же выглядит неестественно. И если ты уже написал спецификацию на Behat, то уже в конце тебе скорее всего не захочется ещё писать тест в PHPUnit, потому что все эти кейсы скорее всего были зафиксированы в спецификации, а это значит, что тесты лучше будет писать в Behat context'ах.
     
    Последнее редактирование: 15 ноя 2017 в 06:01
    fixxxer нравится это.
  16. WMix

    WMix герр M:)ller Партнер клуба

    Сообщения:
    5.924
    Ваш город:
    Berlin
    Address:
    Berlin, Germany
    Country:
    Location on Map:
  17. fixxxer

    fixxxer К.О. Партнер клуба

    Сообщения:
    12.446
    Ваш город:
    Moscow, Russia
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    @WMix, меня сразу смущает "naming-convention based". С такими искусственными ограничениями часто приходится именовать вещи не так, как следовало бы, только чтобы уложиться в эти самые conventions. Да и такая магия, явно основанная на __call(), затрудняет рефакторинг.