Axm
и так в нескольких местах
Aleksandr
положи интерфейс рядом с реализацией в каждом пакете
Aleksandr
package A
type Client interface
type BaseClient struct
package B
type Client interface
type BaseClient struct
Aleksandr
если вообще тебе интерфейсы нужны
Axm
нужны, надо тестировать, а для этого мокать
Axm
спасибо
Мерль
Sapir-Whorf on Programming Languages
https://blog.chewxy.com/2017/09/20/sapir-whorf-programming-languages/
Valentin
по хорошему есть вот такая крайность - каждый пакет у тебя автономная единица, для каждой зависимости имеющая свой интерфейс. и пакеты между собой общаются через адаптеры. но зачастую это оверинжинирнг
Я бы смотрел по обстоятельствам, не все есть смысл декорировать
Aleksandr
Я бы смотрел по обстоятельствам, не все есть смысл декорировать
я именно так и написал. в связанной системе декорация не нужна
Мерль
https://medium.com/@matryer/video-writing-beautiful-packages-in-go-fab1138608ee
Мерль
Anonymous
Чуваки, как все html тэги в строке порезать, без регулярок и strings.Replace?
Мерль
Чуваки, как все html тэги в строке порезать, без регулярок и strings.Replace?
Я использовал вот это
https://github.com/microcosm-cc/bluemonday
Slava
можешь свою написать
🍗
Есть желание попробовать что-то сделать серьезное, типо написать эмуляьтор под ммо игру, если это не утопическая идея, то можете подсказать соответствующую литеруту)
Quet
a tour of go?
Pawel
намекает что за это время можно было бы и библиотеку написать 😉
https://gist.github.com/r0l1/92462b38df26839a3ca324697c8cba04
Valentin
Есть желание попробовать что-то сделать серьезное, типо написать эмуляьтор под ммо игру, если это не утопическая идея, то можете подсказать соответствующую литеруту)
Пиратские северы обычно делают на Java, найди какой-либо и покапайся в коде :)
Pawel
делаю простой DI типа того, как описано в этой статье https://appliedgo.net/di/. если у меня все в разных пакетах, то куда будет по фень-шую засунуть интерфейс? т.е. пакет А с методом М1 требует интерфейс И1. структура с методом, который его реализует, находится в пакете Б. интерфейс надо куда класть? в А, Б или третий пакет?
В статье дальше хелуворда дело не зашло.
Есть мнение, что DI в гошечке - архитектурный костыль. Рудимент, привнесённый рефлесирующими джавистами, пришедшими в Го.
Я не видел DI ни в одном из гайдлайнов, Мэйнтейнеры Го где-то рекомендуют DI? тоже не видел.
Diasko
Pawel
на Go DI это не нужные костыли)
я тоже так считаю. Остаётся понять на чём основаны аргументы противоположного мнения
Valentin
Не надо копипастить 5 раз инициализацию составной структуры
Kirill
Valentin
а конструктор не поможет?
Контейнер как раз решает проблему заполнения конструктора зависимостями
Valentin
Чтобы не приходилось делать это каждый раз
Pawel
Не надо копипастить 5 раз инициализацию составной структуры
В теории - да. Но на практике DI бесполезна и обычно ведет к усложнению кода. Ответь по возможности на несколько вопросов, не обязательно в чатике - просто для себя.
— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации?
— Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации?
— Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно?
— Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?
Pawel
— Как узнать, когда, в каком порядке и с какими аргументами были инициализированы зависимости, использующиеся в конкретной области кода? Как это влияет на debuggability и maintainability кода?
Valentin
Какой то узкий кейс про порядок интциализации. DI же как раз абстрагирует клиентский код от инициализации, создавая зависимости по мере необходимости
Anonymous
что не день, то в этом чате гонят на общепринятый тот или иной темплейт разработки, называя его бесполезным
Axm
Pawel
я пытаюсь придумать случай чтобы порядок инициализации не имел значения. На ум приходит в основном хелуворд. Гошечка в том числе для того и придумана, чтобы прикладной код имел полный контроль над работой системой, а не полагался на неведомую магию
Igor
что не день, то в этом чате гонят на общепринятый тот или иной темплейт разработки, называя его бесполезным
Это потому, что они часто плохо поддерживаются в Go, и "фанатики" считают, раз данный паттерн не поддерживается, то он бесполезен по умолчанию
Igor
я пытаюсь придумать случай чтобы порядок инициализации не имел значения. На ум приходит в основном хелуворд. Гошечка в том числе для того и придумана, чтобы прикладной код имел полный контроль над работой системой, а не полагался на неведомую магию
Если порядок инициализации важен - у вас плохо написан код, с кучей сайд эффектов. Не помню ни одного случая, когда мне нужно было где то соблюдать порядок иницализации
Viktor
Привет всем.
Есть ли сревис или утилитка для генерации struct на основе json ?
Dmitry
Ладно, а как писать тесты с моками?
https://github.com/golang/go/wiki/CodeReviewComments#interfaces
Igor
Привет всем.
Есть ли сревис или утилитка для генерации struct на основе json ?
https://mholt.github.io/json-to-go/
Pawel
Это потому, что они часто плохо поддерживаются в Go, и "фанатики" считают, раз данный паттерн не поддерживается, то он бесполезен по умолчанию
Это потому, что в жабе и C# буквально на каждый чих требуются костыли на подобие DI . Поэтому у жабодрочеров с ООП голвного мозга происходит разрыв шаблона из-за того, что в гошече на фиг не нужно то, что в их говноязыках ситается best pratices.
Anonymous
я не жабодрочер и не любитель ооп, но тоже юзаю DI в го и это удобно
Pawel
Если порядок инициализации важен - у вас плохо написан код, с кучей сайд эффектов. Не помню ни одного случая, когда мне нужно было где то соблюдать порядок иницализации
смысл инициализации в том, чтобы произвести сайд-эффект. Как и императивного программирования вообще. Для того, чтобы понять какие эффекты и в каком порядке вызываются внутри DI контейнера, требуется доп. когнитивная нагрузка по сравнению с прямой конфигурацией зависимостей
Igor
Это потому, что в жабе и C# буквально на каждый чих требуются костыли на подобие DI . Поэтому у жабодрочеров с ООП голвного мозга происходит разрыв шаблона из-за того, что в гошече на фиг не нужно то, что в их говноязыках ситается best pratices.
Вброс "Говноязык" уже как бы указывает на адекватность и объективность мнения
Daniel
коллеги, остановитесь, а?
Daniel
хорошего языка нам не дали еще, а плохие, хоть и прохи все по-разному, плохи одинаково
Igor
смысл инициализации в том, чтобы произвести сайд-эффект. Как и императивного программирования вообще. Для того, чтобы понять какие эффекты и в каком порядке вызываются внутри DI контейнера, требуется доп. когнитивная нагрузка по сравнению с прямой конфигурацией зависимостей
Не должна инициализация объекта вызывать сайд эффекты. Никогда, ни при каких условиях. Откуда это взялось? Есть пример?
Ilia
Не должна инициализация объекта вызывать сайд эффекты. Никогда, ни при каких условиях. Откуда это взялось? Есть пример?
Мне кажется у вас разное понимание сайд эффектов.
Igor
Возможно
Pawel
У некоторых людей како-то имхо карго-культ SOLID или ФП. Объяснять им, что любая loc на Go - это инструкция, производящая сайд-эффект, бесполезно. Рецепт инициализации объектов - это вообще ужос
Anonymous
1. Я бы хотел одну функцию fileExists(), а не две
2. copy(dst, src) - ещё короче и без вопросов
Проверка зависит от ОС и фс а не языка. По юниксу проверяется открытием
Pawel
Возможно, DI и SOLID может быть полезно в очень узкой нише, но слепое следование этим принципам на всех подряд проектах обычно ведет к бессмысленному усложнению кода и нагромождению бесполезных абстракций с визиторами по синглтонам. Почитайте на досуге https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://en.wikipedia.org/wiki/KISS_principle
Pawel
А что это, если не DI?
не вижу каким образом DI облегчит написание тестов. разве что внесёт дополнителную путаницу когда мокается не понятно что и тестируется конь в вакууме.
Igor
@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах
Lanegan
Коллеги, хай! Начал в Go совсем недавно, решил перетащить монолит с php(вот только не надо), на микросервисы. Решил заюзать grpc для общения между сервисами. Такой вопрос, на структуры которые генерятся из protobuf можно полагаться в проекте ? Это норм, реюзать их? Или следует рассматривать эти структуры только как контейнеры для перевозки данных?
Aleksandr
@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах
+1. Я прочел все пассажи про DI с рукой у лица
Daniel
Только для перевозки
Daniel
Не следует вносить связность туда, где без нее можно обойтись
Vasily
Зависит от того насколько плотно ты будешь их спользовать
Daniel
Не зависит
Vasily
Если это микро-сервис, который получил данные из базы и выплюнул наверх - то норм
Если куча-логики ещё там рядом - лучше нет
Daniel
И мы завязали протокол и хранение намертво. Зачем?
Lanegan
Тогда еще вопрос, чем можно копировать значения из одной структуры в другую? Писать свой метод, через рефлектор?
Daniel
Совпадающие на 100% структуры копируются сами
Daniel
Рефлектор - плохое решение
Lanegan
Так вот если они не совпадают?
Daniel
Или руками, или кодогенерацией
Daniel
Я руками пишу
Vladislav
Возможно можно через композицию твои проблемы решить.
Lanegan
Унаследовать структуру которая сгенерилась из protobuf?
Lanegan
Самое простое решение - руками, конечно.
Daniel
Наследовать так же плохо, как на прамую использовать
Vladislav
Никто не мешает менять сами протобаф структуры и в них наследовать. (Ну а вообще копирование не всегда с протобаф связано). Тут нужно частный случай разбирать.
Lanegan
Мне нужно добавить в базу строку с кучей полей(регистрация пользователя), но при этом сам протокол передает больше данных чем надо записать. Плюс для работы с базой выбрал go-pg orm(хотя теперь уже начал сомневаться, нужна ли она... laravel развращает). И тут сами руки тянутся использовать уже готовую структуру, передать в orm и вписать исключения для полей, которых нет в базе.
Lanegan
Но походу таки придется поработать руками. А для документации grpc есть какие-то инструменты ? Или protobuf это и есть документация ?
Kiku
http://telegra.ph/Golang-09-20
Pawel
@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах
Я его использовал когда программировал на C# в asp net mvc. Если вы считаете своё понимаени DI боле труЪшным чем моё, ответьте на заданные выше коварные вопросы в контексте вашей любимой DI системы и приведите примеры из практики, где без DI никуда. Желательно со ссылками на исходники. Подсказать, чем практика отличается от теории?