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

это плохая архитектура

а как надо?

скажите еще, как отделить тест от пакета? чтобы переменные внутри тестов не были доступны пакету остальному. ну или как передать из TestMain нужные значения внутрь тестовых методов, не делая их глобальными?

Ты наверно не понял, про что ведём разговор. Вопрос в том, почему на такой простой функционал каждый прогер должен писать свою реализацию вместо того, чтобы вызвать свою функцию из стандартной либы.

Целый день сегодня про это)

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

еще разверни для понимания связанности пакетов

еще разверни для понимания связанности пакетов

что непонятно? я не знаю куда развернуть надо.

что непонятно? я не знаю куда развернуть надо.

непонятна степень связанности пакетов. я же написал: правильное решение зависит от контекста. пакет зависит от другого пакета - это не контекст.

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

package A type Client1 struct type Client2 interface type Client2BDecorator struct package B type Client2 struct type Client1 interface type Client1ADecorator struct

Интересно

декораторы реализуют интерфейсы своего пакета, декорируя клиентов из другого пакета

не, мне так сложно сейчас не надо, это будет слишком

это в полной парадигме clean arch но этого слишком много для связанных систем

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

и так в нескольких местах

положи интерфейс рядом с реализацией в каждом пакете

package A type Client interface type BaseClient struct package B type Client interface type BaseClient struct

если вообще тебе интерфейсы нужны

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

спасибо

Sapir-Whorf on Programming Languages https://blog.chewxy.com/2017/09/20/sapir-whorf-programming-languages/

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

Я бы смотрел по обстоятельствам, не все есть смысл декорировать

Я бы смотрел по обстоятельствам, не все есть смысл декорировать

я именно так и написал. в связанной системе декорация не нужна

https://medium.com/@matryer/video-writing-beautiful-packages-in-go-fab1138608ee

Чуваки, как все html тэги в строке порезать, без регулярок и strings.Replace?

Чуваки, как все html тэги в строке порезать, без регулярок и strings.Replace?

Я использовал вот это https://github.com/microcosm-cc/bluemonday

Я использовал вот это https://github.com/microcosm-cc/bluemonday

Короче без либ никак?

можешь свою написать

Есть желание попробовать что-то сделать серьезное, типо написать эмуляьтор под ммо игру, если это не утопическая идея, то можете подсказать соответствующую литеруту)

a tour of go?

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

https://gist.github.com/r0l1/92462b38df26839a3ca324697c8cba04

Есть желание попробовать что-то сделать серьезное, типо написать эмуляьтор под ммо игру, если это не утопическая идея, то можете подсказать соответствующую литеруту)

Пиратские северы обычно делают на Java, найди какой-либо и покапайся в коде :)

делаю простой DI типа того, как описано в этой статье https://appliedgo.net/di/. если у меня все в разных пакетах, то куда будет по фень-шую засунуть интерфейс? т.е. пакет А с методом М1 требует интерфейс И1. структура с методом, который его реализует, находится в пакете Б. интерфейс надо куда класть? в А, Б или третий пакет?

В статье дальше хелуворда дело не зашло. Есть мнение, что DI в гошечке - архитектурный костыль. Рудимент, привнесённый рефлесирующими джавистами, пришедшими в Го. Я не видел DI ни в одном из гайдлайнов, Мэйнтейнеры Го где-то рекомендуют DI? тоже не видел.

В статье дальше хелуворда дело не зашло. Есть мнение, что DI в гошечке - архитектурный костыль. Рудимент, привнесённый рефлесирующими джавистами, пришедшими в Го. Я не видел DI ни в одном из гайдлайнов, Мэйнтейнеры Го где-то рекомендуют DI? тоже не видел.

на Go DI это не нужные костыли)

на Go DI это не нужные костыли)

я тоже так считаю. Остаётся понять на чём основаны аргументы противоположного мнения

В статье дальше хелуворда дело не зашло. Есть мнение, что DI в гошечке - архитектурный костыль. Рудимент, привнесённый рефлесирующими джавистами, пришедшими в Го. Я не видел DI ни в одном из гайдлайнов, Мэйнтейнеры Го где-то рекомендуют DI? тоже не видел.

С DI тупо проще

С DI тупо проще

обоснуй

Не надо копипастить 5 раз инициализацию составной структуры

Не надо копипастить 5 раз инициализацию составной структуры

а конструктор не поможет?

а конструктор не поможет?

Контейнер как раз решает проблему заполнения конструктора зависимостями

Чтобы не приходилось делать это каждый раз

Не надо копипастить 5 раз инициализацию составной структуры

В теории - да. Но на практике DI бесполезна и обычно ведет к усложнению кода. Ответь по возможности на несколько вопросов, не обязательно в чатике - просто для себя. — Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? — Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации? — Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно? — Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?

— Как узнать, когда, в каком порядке и с какими аргументами были инициализированы зависимости, использующиеся в конкретной области кода? Как это влияет на debuggability и maintainability кода?

Какой то узкий кейс про порядок интциализации. DI же как раз абстрагирует клиентский код от инициализации, создавая зависимости по мере необходимости

В теории - да. Но на практике DI бесполезна и обычно ведет к усложнению кода. Ответь по возможности на несколько вопросов, не обязательно в чатике - просто для себя. — Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? — Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации? — Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно? — Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?

У вас очень странная практика использования DI

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

В статье дальше хелуворда дело не зашло. Есть мнение, что DI в гошечке - архитектурный костыль. Рудимент, привнесённый рефлесирующими джавистами, пришедшими в Го. Я не видел DI ни в одном из гайдлайнов, Мэйнтейнеры Го где-то рекомендуют DI? тоже не видел.

Ладно, а как писать тесты с моками?

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

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

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

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

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

Привет всем. Есть ли сревис или утилитка для генерации struct на основе json ?

Ладно, а как писать тесты с моками?

https://github.com/golang/go/wiki/CodeReviewComments#interfaces

Привет всем. Есть ли сревис или утилитка для генерации struct на основе json ?

https://mholt.github.io/json-to-go/

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

Это потому, что в жабе и C# буквально на каждый чих требуются костыли на подобие DI . Поэтому у жабодрочеров с ООП голвного мозга происходит разрыв шаблона из-за того, что в гошече на фиг не нужно то, что в их говноязыках ситается best pratices.

я не жабодрочер и не любитель ооп, но тоже юзаю DI в го и это удобно

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

смысл инициализации в том, чтобы произвести сайд-эффект. Как и императивного программирования вообще. Для того, чтобы понять какие эффекты и в каком порядке вызываются внутри DI контейнера, требуется доп. когнитивная нагрузка по сравнению с прямой конфигурацией зависимостей

Это потому, что в жабе и C# буквально на каждый чих требуются костыли на подобие DI . Поэтому у жабодрочеров с ООП голвного мозга происходит разрыв шаблона из-за того, что в гошече на фиг не нужно то, что в их говноязыках ситается best pratices.

Вброс "Говноязык" уже как бы указывает на адекватность и объективность мнения

коллеги, остановитесь, а?

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

смысл инициализации в том, чтобы произвести сайд-эффект. Как и императивного программирования вообще. Для того, чтобы понять какие эффекты и в каком порядке вызываются внутри DI контейнера, требуется доп. когнитивная нагрузка по сравнению с прямой конфигурацией зависимостей

Не должна инициализация объекта вызывать сайд эффекты. Никогда, ни при каких условиях. Откуда это взялось? Есть пример?

Не должна инициализация объекта вызывать сайд эффекты. Никогда, ни при каких условиях. Откуда это взялось? Есть пример?

Мне кажется у вас разное понимание сайд эффектов.

Возможно

У некоторых людей како-то имхо карго-культ SOLID или ФП. Объяснять им, что любая loc на Go - это инструкция, производящая сайд-эффект, бесполезно. Рецепт инициализации объектов - это вообще ужос

1. Я бы хотел одну функцию fileExists(), а не две 2. copy(dst, src) - ещё короче и без вопросов

Проверка зависит от ОС и фс а не языка. По юниксу проверяется открытием

Возможно, DI и SOLID может быть полезно в очень узкой нише, но слепое следование этим принципам на всех подряд проектах обычно ведет к бессмысленному усложнению кода и нагромождению бесполезных абстракций с визиторами по синглтонам. Почитайте на досуге https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://en.wikipedia.org/wiki/KISS_principle

https://github.com/golang/go/wiki/CodeReviewComments#interfaces

А что это, если не DI?

А что это, если не DI?

не вижу каким образом DI облегчит написание тестов. разве что внесёт дополнителную путаницу когда мокается не понятно что и тестируется конь в вакууме.

@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах

Коллеги, хай! Начал в Go совсем недавно, решил перетащить монолит с php(вот только не надо), на микросервисы. Решил заюзать grpc для общения между сервисами. Такой вопрос, на структуры которые генерятся из protobuf можно полагаться в проекте ? Это норм, реюзать их? Или следует рассматривать эти структуры только как контейнеры для перевозки данных?

@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах

+1. Я прочел все пассажи про DI с рукой у лица

Только для перевозки

Не следует вносить связность туда, где без нее можно обойтись

Зависит от того насколько плотно ты будешь их спользовать

Не зависит

Если это микро-сервис, который получил данные из базы и выплюнул наверх - то норм Если куча-логики ещё там рядом - лучше нет

И мы завязали протокол и хранение намертво. Зачем?

Только для перевозки

Соглашусь, спасибо!)

Тогда еще вопрос, чем можно копировать значения из одной структуры в другую? Писать свой метод, через рефлектор?

Совпадающие на 100% структуры копируются сами

Рефлектор - плохое решение

Так вот если они не совпадают?

Или руками, или кодогенерацией

Я руками пишу

Возможно можно через композицию твои проблемы решить.

Унаследовать структуру которая сгенерилась из protobuf?

Самое простое решение - руками, конечно.

Наследовать так же плохо, как на прамую использовать

Никто не мешает менять сами протобаф структуры и в них наследовать. (Ну а вообще копирование не всегда с протобаф связано). Тут нужно частный случай разбирать.

Мне нужно добавить в базу строку с кучей полей(регистрация пользователя), но при этом сам протокол передает больше данных чем надо записать. Плюс для работы с базой выбрал go-pg orm(хотя теперь уже начал сомневаться, нужна ли она... laravel развращает). И тут сами руки тянутся использовать уже готовую структуру, передать в orm и вписать исключения для полей, которых нет в базе.

Но походу таки придется поработать руками. А для документации grpc есть какие-то инструменты ? Или protobuf это и есть документация ?

http://telegra.ph/Golang-09-20

@ruzzke_mir возниакет чувство, что вы вообще не понимаете, что скрывается под буквами DI и разговор идёт о разных вещах

Я его использовал когда программировал на C# в asp net mvc. Если вы считаете своё понимаени DI боле труЪшным чем моё, ответьте на заданные выше коварные вопросы в контексте вашей любимой DI системы и приведите примеры из практики, где без DI никуда. Желательно со ссылками на исходники. Подсказать, чем практика отличается от теории?

Коллеги, использую либу ffjson (кодогенерация), есть структура допустим из 10 полей. 3 из них с тегом json:"-". Нужно уметь маршалить/анмаршалить 7 полей или 10 полей в зависимости от ситуации

Как правильно сделать это? Еще одну структуру завести с полными тегами?