И что поменяется такого страшного, если у вас конструкторы начнут возвращать объекты? Хотите - возвращайте приватные объекты. Да и обычные публичные ни инкапсуляцию, ни разделения слоёв не допустят. Или гайдлайн говорит, что так нельзя?)
Кстати, там выше у вас есть странные штуки, когда есть неиспользуемый ресивер по значению, чтобы "обозначить только для чтения). Лучше не так делать:
Нет, не топлю за функциональное. Вы интересно читаете собеседника: "Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент."
Но мои вопросы вы "не заметили". Так что с теми проблемами, которые добавляют неуместные интерфейсы в вашем коде?
Как-то вы плохо приписываете мне то, чего я не писал. Попробуйте строго пройти по тексту, который выше. Там нет ничего о том, что интерфейсы не нужны. Там о том, что в го они не нужны так, как вы их используете. И обоснования почему: консирукторы с дополнительной зависимостью на интерфейс, который конструируемый тип имплементирует; большая связность кода; убийство фичи duck typing; отсутствие возможности в вашем же коде прокинуть зависимости; и то, что юниты можно не только на моках писать, часто можно обойтить передачей функции. Вы ведь понимаете, что можно DDD и в функциональном подходе иметь? И тестировать не только через тестовые имплементации интерфейса?
И да. Вы так и не ответили на вопрос о том, что у нас любой пакет, который зависит от инплементации заодно зависит и от интерфейса. Что есть прямая дорога к циклическим зависимостям. Да и то, что имплементации зависят от уровня выше не смотрится чисто.
Я пытаюсь показать, что у вас реализация не DDD, а стайлгайда на DDD, притащенного из других языков. И ваш стайлгайд DDD в го работает плохо.
«Я написал, что если без введения интерфейса можно решить задачу и иметь все нужные свойства, то интерфейс добавлять в golang не надо.» Вроде должно отвечать на повторяемый вами вопрос. И да, не моками едиными ) Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент. Хотя по сути аргумент один «так захотелось».
NewAntifraud - как его тестировать, есть зависимости создаются напрямую в конструкторе? То есть вся предыдущая пляска с интерфейсами была не нужна?
MoonRule - не имеет зависимостей, равно не имеет полей и ничего изолировать вообще не надо.
По вашему коду имплементация и интерфейс лежат на одном уровне: MoonRule-AntifraudRule; AndRule-AntifraudRule; и там же интерфейсыUser, Wallet, Money. При таком подходе смысл в интерфейсах не такой большой, поскольку всё лежит в одном большом пакете. Если же разбивать на пакеты то как? Выносить интерфейсы на уровень выше? Но тогда имплементация будет зависеть от уровня выше. Оставлять на том же уровне? Тогда не разрывается зависимость от пакета с имплементацией. Добавлять новый пакет в пакет с имплементацией? Только так останется поступить. Но опять не решенным остается вопрос конструкторов. У вас интерфейсы не уменьшают связность кода, что как-то странно. Должно быть наоборот.
Я написал, что если без введения интерфейса можно решить задачу и иметь все нужные свойства, то интерфейс добавлять в golang не надо. И мне неясна необходимость в большой части интерфейсов в ваших примерах.
Лично я бы и пустые структуры убрал в пользу более функционального подхода. Но вот это уже точно вкусовщина.
Отнюдь. Вопрос про избыточность не снят, поскольку они не решают никакой задачи, которая не может быть решена без их применения. И без возвращения интерфейсов всё будет работать и обладать теми же свойствами.
Главный вопрос к такому подходу в том, что это применение неподходящих инструментов. Это приводит к мысли, что изначальная проблема была не в го, а в конкретном подходе к реализации DDD. Где так и неясно, для чего же надо вводить дополнительные абстракции, если и инкапсуляцию без них можно достичь и разделение слоёв и типов по ответственности.
Не вопрос гайдов. Вопрос "зачем". Тут же не просто гайд, а против самого дизайна языка переть.
Ну иметь сложности с циклическими зависимостями, плодит пакеты, не иметь duck typing, иметь нужду и импортировать пакеты только ради интерфейсов, и прихватить overhead заодно - это понятно. Но зачем? Чем не устраивает обычное разделение на публичные и приватные методы и поля? В чем жизненая необходимость вводить интерфейсы? Какую они задачу решают?
Виктория из "Лица", только сегодня стёр обращение одного из ваших коллег. Настолько удивительное обращение, что хочется с habr поделиться:
"Ваше резюме нас заинтересовало. Мы хотим "пригласить вас на письменное телефонное интервью. Напишите мне, пожалуйста, в будний день в WhatsApp [ссылка на whatsapp с телефоном]. мобильного удобнее – вверху появляется предложение открыть приложение). Укажите в сообщении название данной вакансии и и ваши имя и фамилию (это необходимо, чтобы вся информация по нашему общению сохранилась). Обращаю внимание на просьбу написать, а не звонить. Спасибо!"
Вы серьезно таким спамом занимаетесь и ищите людей в IT? Вы применяете не те методы.
Я думаю, что понял, о чем вы. Вы о trusted setup, генерации подписей и ограничениях на них. Написанное выше не обязательно. Trusted setup, доверенная сторона, ограничения на порядок - это всё не нужно. https://github.com/dedis/kyber/blob/master/share/dkg/rabin/dkg_test.go - можно делать генерацию ключей и без доверенного центра, посмотрите тесты - подписывать там можно в любом порядке. По ссылке выше DKG BLS.
Это не так работает. Приватный ключ никто не собирает - это не нужно по протоколу: мы не собираем приватный ключ, только подпись из подписей каждого.
Если вы про атаку на протокол, когда есть malicious участники, то тогда вам надо больше участников и выше threshold. А далее - нет общих задач, для каждой задачи ищется, что будет для неё безопасным и оптимальным.
Мне, например, приходится обычно работать с количеством участников TSS 50-100. И по условиям протокола и закладывается, что честных 2/3+1. Для пойманных нечестных участников - денежное наказание. Время от времени ключи пересоздаются.
И что поменяется такого страшного, если у вас конструкторы начнут возвращать объекты? Хотите - возвращайте приватные объекты. Да и обычные публичные ни инкапсуляцию, ни разделения слоёв не допустят. Или гайдлайн говорит, что так нельзя?)
Кстати, там выше у вас есть странные штуки, когда есть неиспользуемый ресивер по значению, чтобы "обозначить только для чтения). Лучше не так делать:
```
func (MoonRule) IsDepositAllowed(user User, wallet Wallet, amount Money) (bool, error) {
if IsRisingMoon() {
return true, nil
}
return false, nil
```
Про классику в виде "источники данных могут и меняться". У вас часто на проде базы меняются?) Обычно это очень больно и происходит примерно никогда.
Нет, не топлю за функциональное. Вы интересно читаете собеседника: "Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент."
Но мои вопросы вы "не заметили". Так что с теми проблемами, которые добавляют неуместные интерфейсы в вашем коде?
Как-то вы плохо приписываете мне то, чего я не писал. Попробуйте строго пройти по тексту, который выше. Там нет ничего о том, что интерфейсы не нужны. Там о том, что в го они не нужны так, как вы их используете. И обоснования почему: консирукторы с дополнительной зависимостью на интерфейс, который конструируемый тип имплементирует; большая связность кода; убийство фичи duck typing; отсутствие возможности в вашем же коде прокинуть зависимости; и то, что юниты можно не только на моках писать, часто можно обойтить передачей функции. Вы ведь понимаете, что можно DDD и в функциональном подходе иметь? И тестировать не только через тестовые имплементации интерфейса?
И да. Вы так и не ответили на вопрос о том, что у нас любой пакет, который зависит от инплементации заодно зависит и от интерфейса. Что есть прямая дорога к циклическим зависимостям. Да и то, что имплементации зависят от уровня выше не смотрится чисто.
Я пытаюсь показать, что у вас реализация не DDD, а стайлгайда на DDD, притащенного из других языков. И ваш стайлгайд DDD в го работает плохо.
«Я написал, что если без введения интерфейса можно решить задачу и иметь все нужные свойства, то интерфейс добавлять в golang не надо.» Вроде должно отвечать на повторяемый вами вопрос. И да, не моками едиными ) Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент. Хотя по сути аргумент один «так захотелось».
NewAntifraud - как его тестировать, есть зависимости создаются напрямую в конструкторе? То есть вся предыдущая пляска с интерфейсами была не нужна?
MoonRule - не имеет зависимостей, равно не имеет полей и ничего изолировать вообще не надо.
По вашему коду имплементация и интерфейс лежат на одном уровне: MoonRule-AntifraudRule; AndRule-AntifraudRule; и там же интерфейсы User, Wallet, Money. При таком подходе смысл в интерфейсах не такой большой, поскольку всё лежит в одном большом пакете. Если же разбивать на пакеты то как? Выносить интерфейсы на уровень выше? Но тогда имплементация будет зависеть от уровня выше. Оставлять на том же уровне? Тогда не разрывается зависимость от пакета с имплементацией. Добавлять новый пакет в пакет с имплементацией? Только так останется поступить. Но опять не решенным остается вопрос конструкторов. У вас интерфейсы не уменьшают связность кода, что как-то странно. Должно быть наоборот.
Это не тот вопрос, который я задал ;)
Я написал, что если без введения интерфейса можно решить задачу и иметь все нужные свойства, то интерфейс добавлять в golang не надо. И мне неясна необходимость в большой части интерфейсов в ваших примерах.
Лично я бы и пустые структуры убрал в пользу более функционального подхода. Но вот это уже точно вкусовщина.
Отнюдь. Вопрос про избыточность не снят, поскольку они не решают никакой задачи, которая не может быть решена без их применения. И без возвращения интерфейсов всё будет работать и обладать теми же свойствами.
Главный вопрос к такому подходу в том, что это применение неподходящих инструментов. Это приводит к мысли, что изначальная проблема была не в го, а в конкретном подходе к реализации DDD. Где так и неясно, для чего же надо вводить дополнительные абстракции, если и инкапсуляцию без них можно достичь и разделение слоёв и типов по ответственности.
Для тестов вам надо только принимать параметры по интерфейсу, но не возвращать.
Про изоляцию. У вас конструкторы возвращают интерфейсы вместо самих объектов. То есть вы не убрали, а добавили пакет в зависимости.
Отнюдь. Убираем ненужные интерфейсы и DDD никуда не делось.
Не стоит переделывать мой вопрос.
Не вопрос гайдов. Вопрос "зачем". Тут же не просто гайд, а против самого дизайна языка переть.
Ну иметь сложности с циклическими зависимостями, плодит пакеты, не иметь duck typing, иметь нужду и импортировать пакеты только ради интерфейсов, и прихватить overhead заодно - это понятно. Но зачем? Чем не устраивает обычное разделение на публичные и приватные методы и поля? В чем жизненая необходимость вводить интерфейсы? Какую они задачу решают?
Возвращать интерфейс - не самая лучшая идея в go. Немного похоже на интерфейсы ради интерфейсов.
Заодно начисто убивает идею и преимущества duck typing.
Как правило речь про общий годовой доход до налогов, поскольку налоги по регионам могут и отличаться.
Скорее всего на уровне бизнеса посчитали это редким сценарием, который мало скажется на продажах.
Попробуйте настроить проверку правил форматирования, как часть CI. И ваша жизнь станет лучше.
Надо понимать, что senior разработчики, гады такие, по зарплатам отказываются продавливаться, не входят в положение.
FAAGNЯ? Я - тут точно лишний.
Если у поставщика услуги клиенты "неадекватные", то для бизнеса плохие новости.
Виктория из "Лица", только сегодня стёр обращение одного из ваших коллег. Настолько удивительное обращение, что хочется с habr поделиться:
"Ваше резюме нас заинтересовало. Мы хотим "пригласить вас на письменное телефонное интервью. Напишите мне, пожалуйста, в будний день в WhatsApp [ссылка на whatsapp с телефоном]. мобильного удобнее – вверху появляется предложение открыть приложение). Укажите в сообщении название данной вакансии и и ваши имя и фамилию (это необходимо, чтобы вся информация по нашему общению сохранилась). Обращаю внимание на просьбу написать, а не звонить. Спасибо!"
Вы серьезно таким спамом занимаетесь и ищите людей в IT? Вы применяете не те методы.
Я заранее до собеседований предлагаю кандидату выбрать любой свой код для рассказа о том, что за задачу решал, какой код в итоге получился.
Нет открытого или доступного для демонстрации кода - не беда: предоагаю выбрать любой код на языке из вакансии и рассказать о нём в стиле код ревью.
Я думаю, что понял, о чем вы. Вы о trusted setup, генерации подписей и ограничениях на них. Написанное выше не обязательно. Trusted setup, доверенная сторона, ограничения на порядок - это всё не нужно. https://github.com/dedis/kyber/blob/master/share/dkg/rabin/dkg_test.go - можно делать генерацию ключей и без доверенного центра, посмотрите тесты - подписывать там можно в любом порядке. По ссылке выше DKG BLS.
Это не так работает. Приватный ключ никто не собирает - это не нужно по протоколу: мы не собираем приватный ключ, только подпись из подписей каждого.
Если вы про атаку на протокол, когда есть malicious участники, то тогда вам надо больше участников и выше threshold. А далее - нет общих задач, для каждой задачи ищется, что будет для неё безопасным и оптимальным.
Мне, например, приходится обычно работать с количеством участников TSS 50-100. И по условиям протокола и закладывается, что честных 2/3+1. Для пойманных нечестных участников - денежное наказание. Время от времени ключи пересоздаются.