Size: a a a

2020 May 20

Н

Никита in Go-go!
Dmitry Soloma
приведение типов?
Хм, возможно сработает. Попробую, спасибо
источник

RS

Roman Sharkov in Go-go!
Никита
Как-то задумался, зачем для Бд/очереди/других сервисов которые задействованы в проекте помимо их реализации добавляют еще и интерфейс. Понятно что детали реализации сервисов не должны светиться в бизнес логике, но разве мы не можем делать все методы/поля, которые специфичны для этой реализации делать приватными? Какой смысл в интерфейсе, если публичные методы реализации совпадают с интерфейсом один в один. Мало того, интерфейс не позволяет работать с полями, что бывает крайне неудобно.
Подскажите, может я что-то упускаю?
Для тестирования и рефакторинга.

Интерфейс = late binding (at runtime), что значит что мы в runtime можем поменять конкретную реализацию на которую диспатчатся вызовы методов. С early binding’ом (at compile-time) такое будет невозможно.

Например мы пользуемся gomock с помощью которого используем mock за интерфейсами в тестах
источник

RS

Roman Sharkov in Go-go!
Никита
Как-то задумался, зачем для Бд/очереди/других сервисов которые задействованы в проекте помимо их реализации добавляют еще и интерфейс. Понятно что детали реализации сервисов не должны светиться в бизнес логике, но разве мы не можем делать все методы/поля, которые специфичны для этой реализации делать приватными? Какой смысл в интерфейсе, если публичные методы реализации совпадают с интерфейсом один в один. Мало того, интерфейс не позволяет работать с полями, что бывает крайне неудобно.
Подскажите, может я что-то упускаю?
> Мало того, интерфейс не позволяет работать с полями, что бывает крайне неудобно.

поэтому я и дебатировал тут на днях о том, что нельзя смотреть на интерфейсы как на “абстрактные сущности”.

Пример: Stream плохое название для интерфейса, ибо оно отображает сущность (поток данных). Такой интерфейс должен называться Streamer ибо сразу становится понятно, что это нечто, что читает поток данных и не является самим потоком.

Интерфейс это диспетчер вызова методов. Это актор, который позволяет выполнять действия на каком либо объекте (при этом пользователю интерфейса не должно быть известно к какой конкретной реализации он обращается, ему должно быть пофиг.)
источник

AK

Anton Kucherov in Go-go!
Никита
То есть если вы хотите получить поле, то делаете для него геттер?
Не совсем понимаю о чем вы. Какой Getter? В каком контексте? Какое поле?
источник

V

V---V in Go-go!
В интерфейсах могут быть только методы?
источник

Н

Никита in Go-go!
Anton Kucherov
Не совсем понимаю о чем вы. Какой Getter? В каком контексте? Какое поле?
Ну вот вам нужно поле version. Через интерфейс к нему доступа нет. Вы сделаете метод version который будет возвращать значение поля?
источник

Н

Никита in Go-go!
V---V
В интерфейсах могут быть только методы?
Да
источник

V

V---V in Go-go!
Спасибо
источник

AK

Anton Kucherov in Go-go!
Никита
Ну вот вам нужно поле version. Через интерфейс к нему доступа нет. Вы сделаете метод version который будет возвращать значение поля?
Я все равно не понимаю контекст. Мы про тестировние говорим или о чем?
источник

RS

Roman Sharkov in Go-go!
Никита
То есть если вы хотите получить поле, то делаете для него геттер?
верно. Если вам нужно получить от сущности (конкретного типа) некие данных через интерфейс, то эта сущность должна предоставлять методы чтения этих данных и это даже хорошо.

Хорошо это потому-что в Go многопоточность и работа с полями напрямую порой может привести к data-race’ам. Следственно реализация интерфейса должна позаботиться о том, чтобы доступ к данным был синхронизирован, в случае если интерфейсом будут пользоваться из некосльких горутин одновременно
источник

RS

Roman Sharkov in Go-go!
V---V
В интерфейсах могут быть только методы?
интерфейс ничто иное как набор методов
источник

V

V---V in Go-go!
Откуда название-то такое? Я думал интерфейс это гуй
источник

RS

Roman Sharkov in Go-go!
V---V
Откуда название-то такое? Я думал интерфейс это гуй
GUI = Graphical User Interface

Interface (computing)
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information.
источник

V

V---V in Go-go!
Ключевое слово - графический.. Вон оно как
источник

RS

Roman Sharkov in Go-go!
есть ещё API - application programming interface
источник

AK

Anton Kucherov in Go-go!
Опять в лингвистику ударились. Интерфейс очень обобщенное понятие имеющее разные смыслы в разных контекстах.
источник

V

V---V in Go-go!
Понял, всем спасибо:)
источник

AK

Anton Kucherov in Go-go!
> поэтому я и дебатировал тут на днях о том, что нельзя смотреть на интерфейсы как на “абстрактные сущности”.

An abstract type may provide no implementation, or an incomplete implementation. In some languages, abstract types with no implementation (rather than an incomplete implementation) are known as protocols, interfaces, signatures, or class types.
источник

Н

Никита in Go-go!
Roman Sharkov
верно. Если вам нужно получить от сущности (конкретного типа) некие данных через интерфейс, то эта сущность должна предоставлять методы чтения этих данных и это даже хорошо.

Хорошо это потому-что в Go многопоточность и работа с полями напрямую порой может привести к data-race’ам. Следственно реализация интерфейса должна позаботиться о том, чтобы доступ к данным был синхронизирован, в случае если интерфейсом будут пользоваться из некосльких горутин одновременно
Это да, но обычно у меня такие поля только на чтение
источник

VM

Vladislav Milenin in Go-go!
как можно cookieJar из файла получить? Только вручную парсер писать?
источник