интерфейсы в GO

Что именно не можешь понять?

Примерно то же самое, что в джаве. Ну и везде, где есть интерфейсы.
Кажется, у тебя нет фундаменальных понятий, поэтому го учить матчасть с самых азов.

Примерно то же самое, что в джаве. Ну и везде, где есть интерфейсы.

Кажется, у тебя нет фундаменальных понятий, поэтому го учить матчасть с самых азов.

И где конкретика.

Мне кажется меня запутывают.

https://habr.com/ru/companies/vk/articles/278561/

https://habr.com/ru/companies/vk/articles/278561/

А это ещё не читал.

Благодарю.

Прочитал - шума стало больше - не помогло.

Интерфейс это список требований, которым, в случае ГО, должна отвечать структура (список методов, которые должны быть), чтобы работать единообразно с разными структурами.

Интерфейс – фактически это протокол, по которому можно работать с объектом. В отличии от java и c#, где у интерфейсов номинальная типизация (определяется иерархией наследования), у интерфейсов golang типизация структурная (определяется составом методов и полей). Может из-за этого и непонимание.

интерфейс – это абстрактный класс //с виртуальными методами

не могу что такое интерфейсы в GO

А в каком языке понимаешь? Проще объяснить в сравнении.

Прочитал - шума стало больше - не помогло.

Это не шум. Это та самая недостающая матчасть.

А в каком языке понимаешь? Проще объяснить в сравнении.

Ни на каком, скорее всего.

шума стало больше

Видимо, ты пытаешься игнорировать шум.

Интерфейс описывает поведение.

На пальцах – например что-то что может куда-то писать → т.е. «писатель» io.Writer

type Writer interface {
	Write(p []byte) (n int, err error)
}

будет описывать любую структуру умеющую писать. А в частности любую структуру имеющую метод Write(p []byte) (n int, err error)

Таким образом ты абстрагируешься от конкретного типа и вместо зоопарка

func writeToFile(f *os.File) error
func writeToBuf(b *bytes.Buffer) error
func writeToSocket(n *net.Conn) error

указываешь только поведение, независимое от конкретного типа:

func writeTo(w io.Writer) error

Ибо и os.File и bytes.Buffer и net.Conn и ещё 3000 десятков других структур могут быть «писателем».

Там какая-то полная левая лажа.

Так тут нет поведения. Прост сигнатура, контракт. Поведение будет уже у конкретного типа

Интерфейс это способ сказать в коде что эта переменная или параметр является ссылкой на структуру у которой есть методы перечисленные в интерфейсе. Типа если у тебя в интерфейсе есть методы Beep() и Kill() и Paint(), то ты можешь передать например в функцию любую структуру у которой есть такие методы и внутри функции их вызывать

То есть совершенно то же самое что в жабе например (только в жабе ты должен явно сказать что класс реализует интерфейс, а в гошечке это необязательно

заходишь ты в один магазин, говоришь продавцу что тебе нужно, он тебе дает товар, а ты ему деньги. За ходишь в другой\третий - тоже самое! вот сама концепция продавца и есть интерфейс, хотя сами продавцы могут быть разного пола\возраста и т.д. да и вообще роботом, но реализуют один интерфейс - интерфейс продавца. А вот сама идея, что ты пошел в магазин купить товар взаимодействуя с продавцом-интерфейсом – это уже контрактное программирование.

Похоже на троллинг. Что там понимать? Такие же как и кругом, только есть ещё неявная реализация.

Не советую забивать себе голову этими сектансткими идеями, они далеки от настоящего программирования, больше теория для тех кто любит все усложнять. Может придуманная, чтобы тупые не могли программировать.

Апи чтоли переизобрели? А в чем смысл вводить новое понятие?

Это просто апи и договоренность как в языке нужно создавать апи, чтобы все создавали одинаково и было удобнее. Все.

Возможность из скриптов обращаться к функциям других программ, ОС, ненужная хрень. Ну так-то да.

https://habr.com/ru/companies/vk/articles/278561/

Простейшие понятия расписаны бесполезно многословно.

Лучше бы что-то попроще дал ТСу почитать, например: https://gobyexample.com/interfaces

интерфейс – это абстрактный класс //с виртуальными методами

у абстрактного класса могут быть состояния, а у интерфейса нет

в Го было хорошо и красиво сделано: интерфейс - это набор методов, которые должна реализовывать заданная структура.

Причем в отличие от явно специфицирования, как у бездарей в расте с их трейтами, здесь применяется утиная типизация. То есть если структура уже реализует все нужные методы, то ничего дополнительно указывать не нужно, язык примет ее в качестве заданного интерфейса. Поэтому в Го нет проблем объявлять интерфейсы прямо там, где они используются.

Но сейчас Го сдался, туда пришли эффективные манагеры и начали фигачить дженерики во все поля, превращая язык в ненужную каку вроде раста. RIP.

Структурная типизация круто, спору нет. Но и номинальная иногда полезна бывает. К примеру, не всё, у чего есть метод shoot, можно испольховать для селфи.

Это прям хорошо!

угу, а API это Application Programming Interface
В общем чтобы понять рекурсию, нужно понять рекурсию :-)

ну хорошо
интерфейс – это абстрактный класс без состояния //и с чисто виртуальными методами

Этому понятию лет сорок.

С чистыми виртуальными методами. То есть без реализации.

Ну и данное определение применимо только к C++/Java, потому что завязано на наследовании. В Go есть интерфейс, но нет наследования.

Не понимаю негодования. Сейчас даже в php и python есть дженирики, а уж в языке со статической типизацией без них вообще грустно.

Ну мы же тут объясняем человеку, которому непонятны интерфейсы на Го, а чтобы объяснить надо использовать другие образы, слова, языки…

Ну мы же тут объясняем человеку, которому непонятны интерфейсы на Го, а чтобы объяснить надо использовать другие образы, слова, языки…

В менторском стиле.

начали фигачить дженерик

Которые настолько несовместимы с Го, что выход дальше параметра функции превращается в набор не очевидных проблем. А иногда и с параметрами функции так же.

И вы пишете, пишете, пишете на этих вот генериках. Понимаете, что это нерабочее что-то. Удаляете. И пишите без них. В состоянии абсолютного счастья.

Не понимаю негодования. Сейчас даже в php и python есть дженирики

ну вот пусть эти чудики и пишут на пыхах с питонами, сюда-то они нафиг полезли? Чтобы превратить го в очередное бездарное неюзабельное нечто?

В Горшке интерфейс — это просто набор методов.

Любой тип реализует интерфейс без методов (interface{}).

Тип, имеющий метод String() string реализует интерфейс interface{ String() string }, или, например, fmt.Stringer.

В одном интерфейсе может быть несколько методов. Так же он может включать в себя другие интерфейсы.

Неверно начинать проектирование приложения с интерфейсов. Как правило интерфейсы выявляются позже. При определённом наборе пересекающихся наборов методов у разных типов.

Технически — это структура вида {тип, значение} (или указатели).

Преобразование объекта в интерфейс может привести к выносу этого объекта в кучу.

А какая альтернатива? Как элементарно коллекции в библиотеках реализовать?

Печально. Но go как язык вообще слабоват. Одни слайсы чего стоят.

Го намного сильнее многих других ЯП. В первую очередь потому что изначально он хорошо проработан. А не детсадовская поделка вида: ЯП — это набор фич.

Чиво? Срезы, как раз, там одна из самых класных штук.

Генерация кода, any, рефлексия. Неудобно.

Авторы языка, ЕМНИП, никогда не были против дженериков. Они их просто честно не знали как сделать, как совместить с другими особенностями языка, и были заняты решением других проблем.

Мне кажется, никто не знал как их сделать. Знали, конечно, как их сделать в Java или C++, потому что там они уже есть. Но Go — другой язык и подход дженериков должен быть свой.

Чот там хобот совсем не в ту степь полез объяснять с картинками.

Все же просто:

Интерфейс — это декларативное утверждение того, что может функция/класс, но не показывает, как оно это делает.

Функция/класс — это реализация/имплементация фактических внутренностей того, что заявлено в интерфейсе.

Идея в том, что объяснять много десятками способов. Я привёл один из. Возможно, кому-то зайдёт другой. В любом случае, пока не попробуешь, не поймёшь.

Тебя забанили в гугле, яндексе, бинге, дакдакго и всех ai чатах, что столь простой вопрос надо задавать на ЛОР-е, дёргая живых людей? Плюс-минус тоже самое, что и интерфейсы в других ЯП (синтаксис и некоторые нюансы, вроде встраивания могут отличаться от ЯП к ЯП, но суть и задача у них одна и та же - обеспечивать полиморфизм), в случае го это специальный тип не имеющий реализации.

А как коллекции и операции с ними делать без дженериков? Тип объектов которые туда будут класть неизвестен, потому что откуда я как автор библиотеки должен знать, какую фигню ты будешь вытворять с кодом? Не, можно конечно по старинке, как в сишке с препроцессором или _Generic (С11 и новее) сексом заниматься. Но зачем?

Генерация кода - неудобно, иногда сложно, так уж если код генерить надо чтоб какой-то препроцессор был и желательно удобный и полноценный, скажем питон, но это вместо одного ЯП 2 выходит. Рефлексия не только не удобно, но ещё и на этапе компиляции не вылезет что какое-то говно происходит. Жопа будет прям в рантайме, что добавляет радости с тестами и отладкой кода. Ну нафиг.

Ты не словил фейспалм в начале изучения от неявного владения памятью и еще что еще хуже неявного копирования? И это в достаточно молодом языке, то есть сделано сознательно.

Единственная мегафича это автоасинхронщина, всё остальное либо хуже, либо не лучше чем у других.

Ко времени создания go уже была нормальная реализация дженериков в шарпе. Можно было добавить их с первых версий языка.