> Куда нужно положить интерфейс, если робот реализует интерфейс? (Go)

Короткий ответ

Интерфейс в Go принято размещать на стороне потребителя (consumer), а не на стороне реализации. Если робот реализует интерфейс, интерфейс должен лежать в пакете, который этот интерфейс использует, а не в пакете робота. Это следует из идиомы Go: "interface should belong to the consumer". Такой подход уменьшает связанность, позволяет легко подменять реализации и избегает лишних зависимостей.

Подробное объяснение

В Go интерфейсы - это контракты, которые определяет тот, кто их вызывает. Робот, реализующий интерфейс, не должен знать о самом интерфейсе - он просто предоставляет методы с нужной сигнатурой. Это называется структурной типизацией (structural typing) или утиной типизацией (duck typing).

Если положить интерфейс в пакет робота, то потребитель будет вынужден импортировать пакет робота только ради интерфейса. Это создаёт лишнюю зависимость и нарушает принцип инверсии зависимостей (DIP). Потребитель должен зависеть от абстракции, а не от конкретной реализации.

Правильный подход: интерфейс объявляется в том пакете, где он используется. Например, если у нас есть сервис, которому нужен робот, интерфейс Robot объявляется в пакете сервиса. Робот просто реализует методы, и сервис может использовать любую реализацию, удовлетворяющую интерфейсу.

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

На практике

На практике это выглядит так: пакет robot содержит структуру Robot с методами Move(), Stop(), Charge(). Пакет controller определяет интерфейс:

GO
type Robot interface {
    Move()
    Stop()
}

И использует его в своих функциях. Пакет robot не импортирует controller и не знает о существовании интерфейса. Если позже появится другая реализация - например, Drone - она просто должна иметь те же методы, и controller сможет её использовать без изменений.

Пример кода

GO
// пакет robot
package robot

type Robot struct{}

func (r *Robot) Move() { /* ... */ }
func (r *Robot) Stop() { /* ... */ }
func (r *Robot) Charge() { /* ... */ }

GO
// пакет controller
package controller

type Robot interface {
    Move()
    Stop()
}

func Operate(r Robot) {
    r.Move()
    // ...
    r.Stop()
}

GO
// main.go
func main() {
    r := &robot.Robot{}
    controller.Operate(r) // r удовлетворяет интерфейсу controller.Robot
}

Как отвечать на собеседовании

Начните с короткого ответа: интерфейс принадлежит потребителю. Затем объясните почему: структурная типизация, уменьшение связанности, принцип инверсии зависимостей. Приведите пример с двумя пакетами. Упомяните, что в стандартной библиотеке Go есть примеры интерфейсов, определённых в пакетах-потребителях - например, io.Reader определён в io, но реализуется множеством пакетов. Если спросят про исключения - скажите про интерфейсы для внешних контрактов или общие интерфейсы в отдельных пакетах, но подчеркните, что это редкость.

Что проверяет интервьюер

Интервьюер проверяет понимание идиоматичного Go, принципов SOLID (особенно DIP), умение проектировать зависимости между пакетами. Также важно, что вы понимаете разницу между интерфейсами в Go и интерфейсами в языках с явной реализацией (Java, C#). Это вопрос на архитектурное мышление и знание практик Go-сообщества.

Типичные ошибки

• Размещение интерфейса в пакете реализации - самая частая ошибка, особенно у разработчиков с опытом в Java или C#.
• Создание отдельного пакета для интерфейсов "на всякий случай" - это оверинжиниринг, если интерфейс используется только в одном месте.
• Объявление интерфейса с методами, которые не используются потребителем - интерфейс должен быть минимальным, ровно настолько, насколько нужно.
• Импорт пакета реализации в пакет потребителя только для проверки соответствия интерфейсу - этого делать не нужно, компилятор проверит соответствие автоматически при передаче значения.