для управления массивами
type Obseser interface, так чтоли? // спасибо что не Obser
😂
А методы-то какие?
Start и Stop
Controller?
и будет у вас везде ControllerObses, ControllerMotoroller, etc но по факту это никакой НЕ КОНТРОЛЛЕР, поскольку контроллером будет не интерфейс, а объект!
у меня сомнения, что вы умеете в интерфейсы го
:\ правильно же Controller это объект реализующий интерфейс
Интерфейсы необходимы для доступа к одинаковым полям у разных объектов
Окей. Вот у вас 100500 объектов, и у каждого есть поле id int, и толпа методов которые что-то делают и им важно только это поле. Писать 100500 дублей или же всё-таки сделать интерфейс, который возвращает 1 поле?
Если у тебя 100500 разных объектов с одинаковой семантикой, то ты явно что-то не так делаешь.
Окей, упростим историю. Хочу интерфейс SliceSorter
Хоти дальше :) пока дженерики не введут Но опять же, если тебе надо сортировать кучу разных слайсов, то ты опять же раньше где-то не туда свернул.
Я знаю. Мой поинт в том, что интерфейсами можно обойти отсутствие дженериков.
Есть же готовая реализация в стандартной либе
Окей, а можно без замыкания?
Она строго типизированная, например https://golang.org/pkg/sort/#IntSlice.Swap
Вот же - https://golang.org/src/sort/slice.go?s=396:451#L3
Ну это скорее "интерфейсами можно обойти косяк в архитектуре приложения"
Вы имеете ввиду без функции сравнения, что передаётся? Вроде это каноничный способ ещё с с++ и интерфейса qsort в стандартной библиотеке 🤔
Да, но там как раз less func(i, j int) bool принимается аргументом
Компаратор в определении типа
Попробуйте вынести куда-то функцию-компаратор.
Куда? Вы ее можете определить же в переменную и передавать откуда угодно по указателю, либо я не очень понимаю, что конкретно вынести нужно
https://play.golang.org/p/L4dcZPbK1Cv Попробуйте вынести cmp за пределы main
Обсуждают сегодня