В чем смысл и каковы плюсы/минусы объявления интерфейса на стороне потребителя (по месту использования)?

Ах ты ж ёпта, ну и тема подъехала! Сейчас объясню на пальцах, как это работает, а то некоторые до сих пор путаются, блядь.

Вот смотри, в Го есть такая прикольная фишка — объявление интерфейса на стороне потребителя. Это как если бы ты пришёл в магазин и сказал: «Мне нужна штука, которая открывает бутылки». Тебе похуй, будет это открывалка за сто рублей или навороченный мультитул за десять тысяч — главное, чтобы она открывала, сука. Вот это и есть «принимай интерфейсы».

А когда ты из магазина выходишь, ты возвращаешься с конкретной железкой в руках — вот это «возвращай структуры». Понял, да? Не возвращаешь абстрактную «открывалку», а именно ту самую ржавую китайскую хрень, которую купил.

Плюсы, блядь, какие:

• Хуйни минимум: Ты говоришь, что тебе нужно, и только это. Не тащишь за собой всю библиотеку, как телегу с говном. Нужен метод GetEmail? Вот интерфейс с одним методом и всё, нахуй лишнее.
• Связанность низкая, как твоя самооценка после пятницы: Твоему коду похуй, откуда пришла реализация. Может, из базы данных, а может, её мартышка на клавиатуре нагенерила. Главное — методы есть.
• Тестирование — раз плюнуть: Захотел потестить — подсунул в ротберунчик какую-нибудь заглушку, которая всегда test@example.com возвращает. Никаких танцев с бубном и импортов левых пакетов для моков.
• Реализация неявная, как намёк твоей тещи: Структуре даже знать не надо, что ты там интерфейс придумал. Есть у неё методы с нужными сигнатурами? Отлично, она уже реализует. Волшебство, ёпта!

Минусы, куда ж без них:

• Интерфейсы множатся, как тараканы: Если пять сервисов хотят одно и то же, но чуть по-разному, будет пять почти одинаковых интерфейсов. Дублирование, блядь, чувствую подозрение.
• Можно перестараться и сделать интерфейс на один чих: Такой узкий, что кроме твоего конкретного случая он никому нахуй не сдался. Пиздопроебибна получается.

Смотри пример, чтобы вообще всё встало на свои места:

Допустим, есть у нас сервис Notifier, который шлёт уведомления. Ему главное — достать email пользователя. Как достанет — его проблемы.

package notifier

import "fmt"

// 1. Вот наш потребитель (notifier) заказывает себе "штуку, которая даёт email".
// Ему больше ничего не надо, хитрая жопа.
type UserGetter interface {
    GetEmail(userID int) (string, error)
}

// Notifier теперь работает с абстракцией. Ему похуй на реализацию.
type Notifier struct {
    userSource UserGetter
}

func (n *Notifier) Notify(userID int, message string) error {
    email, err := n.userSource.GetEmail(userID)
    if err != nil {
        return err
    }
    fmt.Printf("Шлю '%s' на %sn", message, email)
    // ... тут реальная отправка
    return nil
}

// --- А теперь в другом углу ринга, в пакете `storage` ---

package storage

// 2. Реализация. Она живёт своей жизнью и ни о чём не подозревает.
type PostgresUserDB struct {
    // ... тут connection pool и прочая муть
}

// 3. Но методы-то у неё есть! Совпадение? Не думаю.
func (db *PostgresUserDB) GetEmail(userID int) (string, error) {
    // Лезет в PostgreSQL, достаёт почту
    return fmt.Sprintf("user%d@example.com", userID), nil
}

// Собираем всё в кучу в main.go
func main() {
    db := &storage.PostgresUserDB{} // Конкретная железка (структура)
    // Передаём её в notifier. Она подходит, потому что метод GetEmail есть.
    notifierSvc := &notifier.Notifier{
        userSource: db, // Неявная реализация работает!
    }
    notifierSvc.Notify(123, "Заказ готов, приходи!")
}

Вот и вся магия, блядь. Потребитель говорит, что ему надо, а поставщик (реализация) даже не в курсе, что его так используют. Гибко, удобно, и связанности — ноль ебать. Главное — не наделать интерфейсов на каждый чих, а то захуяришься потом.