S
Size: a a a
2020 April 13
DP
если честно - сам я так не думаю. но я теорией не интересовался.
AK
Если мои функции принимают интерфейс, который можно реализовать в разных вариантах в разных пакетах - это dependency injection?
Ваша функция зависит (depends on) от этих интерфейсов ведь? Она их вызывает внутри. Раз вы их туда передаете? Так почему нет?
x
В реальности же сами по себе глобальные переменные не являются злом, и все это прекрасно понимают.
Мы, скажем вынуждены использовать все вот эти
Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
Мы, скажем вынуждены использовать все вот эти
var ErrSome = errors.New(...).Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
S
Ваша функция зависит (depends on) от этих интерфейсов ведь? Она их вызывает внутри. Раз вы их туда передаете? Так почему нет?
Да, передаю, и да, получается что депендится)
DP
Ваша функция зависит (depends on) от этих интерфейсов ведь? Она их вызывает внутри. Раз вы их туда передаете? Так почему нет?
я бы придумал такое определение di, которое позволяло бы отличать di от передачи параметров. а то di становится совершенно бессмысленным понятием
АП
если есть система управления зависимостей - di
если нет - обычная передача параметров
если нет - обычная передача параметров
DP
В реальности же сами по себе глобальные переменные не являются злом, и все это прекрасно понимают.
Мы, скажем вынуждены использовать все вот эти
Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
Мы, скажем вынуждены использовать все вот эти
var ErrSome = errors.New(...).Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
> Мы, скажем вынуждены использовать все вот эти var ErrSome = errors.New(...).
это не переменная, а квазиконстанта. и она оформлена как переменная только потому, что константы в go убогие
это не переменная, а квазиконстанта. и она оформлена как переменная только потому, что константы в go убогие
АП
я бы так рассудил
ВГ
В реальности же сами по себе глобальные переменные не являются злом, и все это прекрасно понимают.
Мы, скажем вынуждены использовать все вот эти
Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
Мы, скажем вынуждены использовать все вот эти
var ErrSome = errors.New(...).Было бы лучше без них (но не потому что это глобальные переменные), но, тем не менее, все мы (ну или большинство) это используем.
Есть глобальные переменные для конфигов.
Не все их используют, есть способы более удобные, но те, кто используют тот же go-swagger, знают, что конфиги (опции запуска) там задаются через глобальную переменную.
Всё это есть.
Никто не пытался сказать, что глобальные переменные — суть зло.
Но когда мы говорим о каких-то зависимостях, когда мы говорим о тестировании, о стабильности разработки и поддержки в хоть сколько-нибудь архитектурно серьёзных продуктах, мы сталкиваемся с тем, что объявленные глобальными переменными зависимости типа коннекта к БД могут создать неудобства.
Могут и не создать. А может для кого-то невозможность замокать тестируемый объект и не является неудобством.
Каждый имеет право на своё независимое мнение. И вы тоже. Странно только, что вы так любите спорить с теми, кто так же как и вы имеет право на мнение, при этом требуя каких-то доказательств и не предоставляя их со своей стороны.
Ваше "за всё время не было проблем" — это же не доказательство. Какое время?
Что за проекты?
Вот мой пример раскритиковали, предложив использовать интерфейс и вообще вынести всё это дело в контроллер. И правильно раскритиковали, потому что в большинстве случаев так действительно будет проще в дальнейшем. Я правда этот пример приводил не как пример окончательного решения, а как пример того, как можно без глобальной переменной. Но это уже моя проблема — нужно было сразу уточнять этот момент.
Видите, всегда можно разговаривать конструктивно, а не гадить на стол в ресторане, выкрикивая "я прав, докажите обратное".
Мимо
просто в Го нет глобальных переменных
ВГ
в том смысле, которым они клеймились, как зло
DP
просто в Го нет глобальных переменных
конечно, есть. любая экспортируемая переменная уровня пакета доступна глобально
ВГ
а зло они - в Си, потому что там неймспейсов нет
ВГ
а тут она все равно в скоупе модуля сидит
DP
это не помогает от проблем глобального стейта никак :(
а
это не помогает от проблем глобального стейта никак :(
+
x
> Мы, скажем вынуждены использовать все вот эти var ErrSome = errors.New(...).
это не переменная, а квазиконстанта. и она оформлена как переменная только потому, что константы в go убогие
это не переменная, а квазиконстанта. и она оформлена как переменная только потому, что константы в go убогие
Это я в курсе. Об этом и речь, будь возможность задавать ошибки константами, было бы удобней. Но возможность нет, поэтому глобальные переменные (не важно что они квази, они же от этого по факту не перестают быть глобальными переменными).
К слову, не только в Go такие константы, но это и не важно. Что имеем то имеем.
К слову, не только в Go такие константы, но это и не важно. Что имеем то имеем.