@
Size: a a a
2020 May 05
DP
чтобы можно было передать разные имплементации под одной вывеской (вывеска - это интерфейс и есть)
AK
хорошо, зачем нужен тогда интерфейс если есть структура?
Ну вы можете подставить в рантайме вместо интерфейса конкретную реализацию
DP
Ну вы можете подставить в рантайме вместо интерфейса конкретную реализацию
“должны будете”
AK
Да точно должны будете
AK
Можете и не подставить но тогда все упадет
EK
хорошо, зачем нужен тогда интерфейс если есть структура?
Структур может быть 10 разных.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
@
Структур может быть 10 разных.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
да, так понятно стало. Спасибо
V
Структур может быть 10 разных.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
У них могут быть разные методы.
Но тебе нужно на вход принимать любую структуру, с которой, например, можно читать байты.
Поэтому ты пишешь интерфейс в котором будет метод Read и ожидаешь на вход именно этот интерфейс.
И пока у твоей структуры есть такой метод Read - ты можешь туда подсунуть ЛЮБУЮ структуру, а не какую-то конкретную.
При этом, тебе не нужно явно указывать в твоей структуре, что она соответствует твоему интерфейсу. Go сам за тебя проверит это. Ему достаточно знать, что у структуры есть нужный метод.
О, очень красивое объяснение, спасибо. Тоже периодически путаюсь.
Фактически это похоже на динамическое применение ключевого слова implements из java, которое компилятор сам подставляет в контексте.
Т.е. компилятор видит, что функция на вход хочет такой-то интерфейс, проверяет, что переданная структура соответствует этому интерфейсу (наличие нужных методов) и выдаёт ошибку, если нужных методов нет.
Верно?
Фактически это похоже на динамическое применение ключевого слова implements из java, которое компилятор сам подставляет в контексте.
Т.е. компилятор видит, что функция на вход хочет такой-то интерфейс, проверяет, что переданная структура соответствует этому интерфейсу (наличие нужных методов) и выдаёт ошибку, если нужных методов нет.
Верно?
DP
верно
МП
Тест без моков для функции которая вызывает другие функции или методы внутри себя - интеграционный тест. Так лучше? Или с этим тоже поспорите? Приведите пожалуйста аргументы почему это абсурд?
потому что есть property based + table driven тестирование, которое точно такое же модульное, как и тестирование на основе моков?
DP
Мимо Проходящий
потому что есть property based + table driven тестирование, которое точно такое же модульное, как и тестирование на основе моков?
коллега, а не ортогонально ли это?
МП
коллега, а не ортогонально ли это?
нет, не "ортогонально". Всё это про тестирование отдельных кусков кода
МП
Если код объектно-ориентированный (на интерфейсах), его тестируют моками. Если код "математический" (на чистых функциях), его тестят более строгими методами, вот и всё
DP
насколько я знаю, тестят код примерно одинаково и тот, и другой, а моки только обеспечивают возможность тестирования
М
Мимо Проходящий
Берём пример алгоритма - bfs графа. Есть тест,который говорит о том, что реализация не верна. И есть косяк реализации - пройденные вершины не правильно помечаются. Дебагер покажет этот косяк мгновенно. Тест не покажет.
Я вообще не понимаю спора «тесты vs дебаггер»
Нужно использовать и то и то, причём одновременно.
Например вчера мне дебаг тестов помог пофиксить баг в довольно сложном конкурентном коде за счёт того, что точку прерывания можно повесить в кишках стандартной библиотеки и отловить краевой случай
Нужно использовать и то и то, причём одновременно.
Например вчера мне дебаг тестов помог пофиксить баг в довольно сложном конкурентном коде за счёт того, что точку прерывания можно повесить в кишках стандартной библиотеки и отловить краевой случай
DP
Я вообще не понимаю спора «тесты vs дебаггер»
Нужно использовать и то и то, причём одновременно.
Например вчера мне дебаг тестов помог пофиксить баг в довольно сложном конкурентном коде за счёт того, что точку прерывания можно повесить в кишках стандартной библиотеки и отловить краевой случай
Нужно использовать и то и то, причём одновременно.
Например вчера мне дебаг тестов помог пофиксить баг в довольно сложном конкурентном коде за счёт того, что точку прерывания можно повесить в кишках стандартной библиотеки и отловить краевой случай
как так получается, что мне ни разу не понадобился дебагер с 2001 года?..
МП
насколько я знаю, тестят код примерно одинаково и тот, и другой, а моки только обеспечивают возможность тестирования
с этим я согласен конечно, в моках может быть что угодно, в т.ч. проверка по таблице или quick check Ну так не все же функции и алгоритмы используют интерфейсы, а тестировать надо все