Emil
О, и правда, можно
Ivan
А в месте использования это где? Мне так нравилось, как везде возвращается интерфейс
видимо в http/handler
Herman
func NewCurService(apiKey string) ICurrency {
return &curService{ApiKey: apiKey}
} , лучше возвращать конкретный тип. а интерфейс обьявлять в месте использования
а вообще есть какой-то физический смысл возвращать интерфейс?
Herman
в каких-то кейсах
Herman
как я понимаю нету
Herman
Accept interfaces, return structs - рандомная цитата
Ivan
вроде net.Deal возвращает Conn интерфейс
Ivan
видимо функции с хитрой логикой и могут возвращать интерфейс. но конструкторы то лучше конкретный тип наверно)
Herman
конструкторы конечно, они ж конструируют тип)
Herman
а вот в чем хитрость логики может быть
Ivan
ну типо CreateAnimal("dog") Animal { return &Dog{}}
Herman
боюсь представить, какой там свитч будет)
Herman
забавно, что в https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/net/dial.go
Herman
идут сначала приватные функции
Herman
м
Herman
Herman
то есть у них свитч
Herman
и они не могут вернуть какую-то реалзиацию
Herman
поэтому интерфейс
Anonymous
герман ревьювит код
Anonymous
джуны налетайте
Emil
Herman
Herman
я ж в го вообще недавно
Emil
вот если будет так, то вернешь интерфейс)
когда в функции на выбор может вернуться одна из нескольких структур, которая удовлетворяет общему интерфейсу?
Herman
да
Emil
Ну, пойду переписывать
Спасибо
Herman
Как, кстати, лучше, если у тебя FinanceService?
Herman
FinanceServicer?)
Herman
FinanceServiceAdapter
Herman
Не знаю
Emil
Давным давно слышал где-то, что название интерфейса это название структуры + заглавная И
Но да, ввиду нескольких удовлетворяющих структур да и смысла интерфейсов, это наверное не особо смысл имеет
Вот да, видел еще много создания названий исполнителей er, но как-то странно звучит
Herman
Хороший вопрос
Herman
Ну или не только в нем, но в моем опыте так
Anonymous
заглавная I указывает на business intent
Anonymous
а если без нее то на technical intent
Anonymous
что-то такое
Ivan
назвать переменную - самое сложное(
Anonymous
хз, я слышал про интент
Herman
В го есть же рекомендация с er на конце, но пока ни разу не получилось так назвать
Ivan
io.Reder io.Writer интерфейсы из 1 функции
Ivan
просто где будет использоваться FinanceService сделать интерфейс BalanceGeter или transactionMaker
Herman
просто где будет использоваться FinanceService сделать интерфейс BalanceGeter или transactionMaker
Так а если нужны все функции?
Herman
Если у нас есть репозиторий 50 методов, и сервис
Herman
Вообще может такая архитектура не про го, поэтому и такие вопросы возникают
Herman
А какая тогда про го
Ivan
сложно представить функцию в которой используются все 50 методов от интерфейса) Значит нужно придумать емкое название
Ivan
тотже net.Conn там чет с десяток методов
Herman
Herman
Ну есть сервис, по классике в него кладётся интерфейс репозитория
Herman
Функции сервиса дергают репу
Ivan
можно в сервис положить не интерфейс а конкретный тип репозитория, а в репозиторий уже интерфейс подключения к базе
Herman
а если несколько репозиториев?
Herman
в том плане, например, бд, файл, инмемори
Herman
еще че-нить
Ivan
как он один будет. вся логика в нем. а бд или файл это уже будет интерфейс не зависящий не от сервиса не от репозитория
Vitaliy
Кстати!
Vitaliy
Как мы, коллеги-гошники, логгирование тестим?
Vitaliy
ТЕстим в тестах
Vitaliy
не на проде
Vitaliy
юнит-тестим
Vitaliy
ожидается, что функция съэмиттит один лог-энтри, если функция будет запущена. Такой абстрактный пример
Vitaliy
МОКИ?
Vitaliy
=)
Vitaliy
Вот у меня logrus
Vitaliy
Мне постоянно надо переусложнять сигнатуры функций, чтобы тащить мок-стрим для логирования?
Vitaliy
лулъ
Vitaliy
Да, это не чистая функция
Vitaliy
Но у нас не хаскель
Vitaliy
🅞leksiy
Не совсем понял смысл выше сказанного, тестировать логгирование? Можно пример?
Артур
Тестировать структуру и данные, которые отправляются в лог.
Raniqubihe
почему так нельзя?
Raniqubihe
var my_str = "Hello_world"
strings.Replace(my_str,"o","")
fmt.Print(my_str)