Исходя из вашего(!) объяснения интерфейсы нафиг не упали. Нужно было создавать вторую структуру(именно структуру, а не экземпляр n2) создать функцию с сигнатурой на основе интерфейса и передать ей на вход разные структуры. А вы показали как загромоздить код, совершенно не нужным интерфейсом.
Интерфейсы часто нужны когда ты не один код пишешь. И, допустим, кто-то пишет как сохранять логи в бд, а кто-то на диск. Структура которая это будет делать - не париться как именно. Но нужно, что бы всегда были одинаковые названия методов. Вместо того, что бы лично договариваться, какие методы использовать, кто-то один раз интерфейс пропишет, а потом оба программиста будут его реализовывать, каждый под свое хранилище. Если он не реализует какой-то метод - то будет ошибка. И мало того, если появится какой-то третий способ сохранения данных (допустим в облаке), новый программист, глянет какой интерфейс и опять создаст свою реализацию, даже через год или два.
Интерфейсы нужны не для наследования методов, интерфейсы нужны для уменьшения связанности между разными частями кода программы. Интерфейсы - это реализация одного из принципов SOLID. Вы передаёте в метод какую-то структуру, реализующую какой-то интерфейса, а как именно эта структура реализует тот или иной метод интерфейса вас не волнует.
Я не понимаю, хоть убей. Зачем они нужны. ЧТо Java что c# что тут в GO. Зачем и для чего нужны интерфейсы, какова их роль. Есть какой то пример наглядный то есть такая ситуация прям что бы было четко видно что надо использовать именно интерфейсы???
Структура:Самолет -> метод: летает Структура:Утка -> метод: летает Вопрос: как написать 1 функцию которая на вход будет принимать все структуры с методом "летает"? Создаем ОПГ "Летающие", все структуры, которые умеют летать - входят в это ОПГ. Функции говорим, принимай всех из ОПГ "Летающие", а не пишем функции под каждую структуру (Самолет,Утка ). P.s ОПГ "Летающие" и есть интерфейс. Если не понятно представь что таких структур не 2, а 100 ,тогда придется 100 функций написать.
Допустим, у тебя есть программа, которая считает зарплату сотрудников исходя из должности и количества выработанных часов. Одна компания передаст эти данные формате xml, другая в json, а третья через БД. Самой логике расчёта безразлично как мы получили эти данные, поэтому разумно написать одну функцию, в которую передадим интерфейс, а не три функции с одинаковой логикой под каждый формат. Даже при трёх форматах удобство одной функции очевидно, а теперь представь, что к этому захотят добавить ещё способы. Тут мы ещё раз порадуемся, что сделали интерфейс. При работе со сторонними библиотеками интерфейсы так же могут быть полезны, если мы захотим сделать возможным передать эти данные в формате, который не предусмотрен разработчиком оригинальной библиотеки. В общем, очень полезная тема в которой нужно разобраться.
В общей алгебре множество чего-то, что можно складывать, вычитать, умножить и делить называют Полем, а без деления - Кольцом. Так что можно было назвать интерфейс более корректно :)
Отлично, меня радует go! Задумываюсь о переносе проектов на него.
Это хороший вариант для переноса на него проектов благодаря своей производительности
Странно , комментарии исчезают, пытаюсь написать о том что пхп как и апач умирают постепенно.
Тоже заметил пропажу комментов(
Насчёт PHP не всё так однозначно, но он действительно вытесняется более современными технологиями
Здесь особо переписываться не дают , люди создают каналы в телеграмме , есть даже группы в signal
ТГ канал есть, но я им особо не занимаюсь 😂
Вот думаю может и туда что-то постить
Красава, спасибо. Первый видос по интерфейсам где просто и доступно.
Исходя из вашего(!) объяснения интерфейсы нафиг не упали.
Нужно было создавать вторую структуру(именно структуру, а не экземпляр n2) создать функцию с сигнатурой на основе интерфейса и передать ей на вход разные структуры.
А вы показали как загромоздить код, совершенно не нужным интерфейсом.
спасибо, разобрался с интерфейсами
Интерфейсы часто нужны когда ты не один код пишешь. И, допустим, кто-то пишет как сохранять логи в бд, а кто-то на диск.
Структура которая это будет делать - не париться как именно. Но нужно, что бы всегда были одинаковые названия методов.
Вместо того, что бы лично договариваться, какие методы использовать, кто-то один раз интерфейс пропишет, а потом оба программиста будут его реализовывать, каждый под свое хранилище. Если он не реализует какой-то метод - то будет ошибка. И мало того, если появится какой-то третий способ сохранения данных (допустим в облаке), новый программист, глянет какой интерфейс и опять создаст свою реализацию, даже через год или два.
Спасибо дружище, что объясняешь простым языком! 👍. Давай ролик Конкурентность и Паралелизм. А то понять сложно, нужно чтобы простым языком объяснили)
Интерфейсы нужны не для наследования методов, интерфейсы нужны для уменьшения связанности между разными частями кода программы. Интерфейсы - это реализация одного из принципов SOLID. Вы передаёте в метод какую-то структуру, реализующую какой-то интерфейса, а как именно эта структура реализует тот или иной метод интерфейса вас не волнует.
В таком случае расскажи что такое интерфейсы, потому что я думаю не один сломался на этой теме.
С интерфейсами все понятно, меня збиваэт только одно. Зачем в функции используетьс возврат?
Метод отнятия.... это здорово ))😆
может ты, уникум, по украински хоть слово сказать сможешь? или все люди мира обязаны знать русский в идеале?
@@user-22-505 Могу. Підсрачник 😂
@@user-22-505 перемога или зрада?
Я не понимаю, хоть убей. Зачем они нужны. ЧТо Java что c# что тут в GO. Зачем и для чего нужны интерфейсы, какова их роль. Есть какой то пример наглядный то есть такая ситуация прям что бы было четко видно что надо использовать именно интерфейсы???
Автор сам не разобрался, посмотри другое
Структура:Самолет -> метод: летает
Структура:Утка -> метод: летает
Вопрос: как написать 1 функцию которая на вход будет принимать все структуры с методом "летает"?
Создаем ОПГ "Летающие", все структуры, которые умеют летать - входят в это ОПГ.
Функции говорим, принимай всех из ОПГ "Летающие", а не пишем функции под каждую структуру (Самолет,Утка ).
P.s ОПГ "Летающие" и есть интерфейс.
Если не понятно представь что таких структур не 2, а 100 ,тогда придется 100 функций написать.
Допустим, у тебя есть программа, которая считает зарплату сотрудников исходя из должности и количества выработанных часов.
Одна компания передаст эти данные формате xml, другая в json, а третья через БД. Самой логике расчёта безразлично как мы получили эти данные, поэтому разумно написать одну функцию, в которую передадим интерфейс, а не три функции с одинаковой логикой под каждый формат. Даже при трёх форматах удобство одной функции очевидно, а теперь представь, что к этому захотят добавить ещё способы. Тут мы ещё раз порадуемся, что сделали интерфейс. При работе со сторонними библиотеками интерфейсы так же могут быть полезны, если мы захотим сделать возможным передать эти данные в формате, который не предусмотрен разработчиком оригинальной библиотеки. В общем, очень полезная тема в которой нужно разобраться.
топчик
забыли сказать что структуры в 3 раза медленнее обычных функций
Subtract, не substract
В общей алгебре множество чего-то, что можно складывать, вычитать, умножить и делить называют Полем, а без деления - Кольцом. Так что можно было назвать интерфейс более корректно :)
Так проще и правильнее:
func main() {
namber := Nambers{5, 4}
fmt.Println("Сумма: ", namber.sum())
fmt.Println(namber.minus())
fmt.Println(namber.delen())
fmt.Println(namber.umnoz())
}
написано неправильно и на английском русском, но безусловно лаконичнее