ЗА
Да, т.к. в случае изменения зависимости придется переработать больше кода, чем только вызов фабрики.
Это все очень абстрактно
Size: a a a
2020 June 07
s
А скажите пожалуйста, почему в этих языках вы экспортируете интерфейс? что мешает экспортировать реализацию и подставлять ее туда где параметром является интерфейс?
смотрите, постараюсь понятнее
в других языках мы определяем интерфейс например Storage и везде где нам нужен Storage мы используем этот интерфейс
в го принят другой подход - мы определяем интерфейс когда нам нужно здесь и сейчас абстрагировать какое то поведение
в других языках мы определяем интерфейс например Storage и везде где нам нужен Storage мы используем этот интерфейс
в го принят другой подход - мы определяем интерфейс когда нам нужно здесь и сейчас абстрагировать какое то поведение
VL
Это все очень абстрактно
А самое главное, что очень часто используется только одна реализация (не пишут юниты и не мокают) и интерфейсы не нужны.
AK
смотрите, постараюсь понятнее
в других языках мы определяем интерфейс например Storage и везде где нам нужен Storage мы используем этот интерфейс
в го принят другой подход - мы определяем интерфейс когда нам нужно здесь и сейчас абстрагировать какое то поведение
в других языках мы определяем интерфейс например Storage и везде где нам нужен Storage мы используем этот интерфейс
в го принят другой подход - мы определяем интерфейс когда нам нужно здесь и сейчас абстрагировать какое то поведение
Я спрашиваю почему мы так делаем в других языках, а в Go иначе? Вы говорите: Потому что под интерфейсами другая "идея". Я говорю: потому что реализовано по разному (А идея одинаковая). И в других языках и в Go мы используем интерфейс чтобы абстрагировать хранилище. Т.е. идея одна и та же. Не видите здесь противоречия?
ЗА
Не ребят, это просто соблюдение правил ради правил. В примере выше шанс, что сервис начнёт реализовывать другой интерфейс, а не свой, близок к нулю
s
Я спрашиваю почему мы так делаем в других языках, а в Go иначе? Вы говорите: Потому что под интерфейсами другая "идея". Я говорю: потому что реализовано по разному (А идея одинаковая). И в других языках и в Go мы используем интерфейс чтобы абстрагировать хранилище. Т.е. идея одна и та же. Не видите здесь противоречия?
идеи разные, задачи теже
в других языках по другому потому что они другие, как уже сказали выше например нет утинной типизации
в других языках по другому потому что они другие, как уже сказали выше например нет утинной типизации
VL
Не ребят, это просто соблюдение правил ради правил. В примере выше шанс, что сервис начнёт реализовывать другой интерфейс, а не свой, близок к нулю
Преждевременная абстракция - это также плохо, как и преждевременная оптимизация.
AK
идеи разные, задачи теже
в других языках по другому потому что они другие, как уже сказали выше например нет утинной типизации
в других языках по другому потому что они другие, как уже сказали выше например нет утинной типизации
Отсутвие утиной типизации - есть деталь реализации.
s
Отсутвие утиной типизации - есть деталь реализации.
это например как с метриками, есть пуш подход, а есть пул, задачи одинаковые идеи разные
AK
Да одни и те же идеи и в Go и в Java интерфейс задает "Контракт API". Только в Java отличается реализация и поэтому надо явно говорить компилятору что тот или иной класс реализует этот контракт. А Go сам способен догадаться.
НМ
а я вот не хочу участвовать в сраче но просто хочу поддержать @antonikucherov , выразив солидарность )
s
Да одни и те же идеи и в Go и в Java интерфейс задает "Контракт API". Только в Java отличается реализация и поэтому надо явно говорить компилятору что тот или иной класс реализует этот контракт. А Go сам способен догадаться.
это разные подходы, они разные не только потому что реализованы по разному, они в принципе подразумевают несколько "мыслить немного по другому"
VL
Да одни и те же идеи и в Go и в Java интерфейс задает "Контракт API". Только в Java отличается реализация и поэтому надо явно говорить компилятору что тот или иной класс реализует этот контракт. А Go сам способен догадаться.
Разницы нет никакой. Тут вопрос про то, что рекомендуемый подход позволяет коду определить требуемое поведение, а не зависимости его диктовать. Так-то от адаптеров никто не отказывается.
НМ
как уже правильно отметил товарищ Подольский, интерфейы в го нужны ровно для того же, для чего нужны в других яп - обеспечиать low coupling , все остальное - детали имплементации
s
как уже правильно отметил товарищ Подольский, интерфейы в го нужны ровно для того же, для чего нужны в других яп - обеспечиать low coupling , все остальное - детали имплементации
да, задачи у них одинаковые, с этим же никто не спорит
AK
Предпосылка о том, что:
- Если у нас есть одна реализация, абстракция не нужна и является преджевременной, на мой взгляд в корне не верна.
- Если у нас есть одна реализация, абстракция не нужна и является преджевременной, на мой взгляд в корне не верна.