Практическая ситуация: определите, удовлетворяет ли S интерфейсу Worker, и объясните роль одноимённого поля...

package main

type Worker interface {
	Work()
}

type Base struct{}

func (Base) Work() {}

type S struct {
	Base
	Work int
}

var _ Worker = S{}

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

S не удовлетворяет интерфейсу Worker: компилятор не считает promoted-метод Base.Work методом S, потому что одноимённое поле S.Work скрывает его. В результате выражение var _ Worker = S{} завершается ошибкой компиляции.

Исторический контекст

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

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

Постановка проблемы

У Base есть метод Work, а у S — встроенное поле Base и собственное поле Work. При обращении к s.Work имя разрешается в пользу поля S.Work; продвигаемый метод Base.Work не входит в методный набор S как доступный метод.

Попытка присвоить S{} переменной типа Worker приводит к ошибке вида: S does not implement Worker (S.Work field is not a method). Ошибка особенно неприятна при рефакторинге: добавление поля может незаметно сломать реализацию интерфейса.

Подробное решение

Методы встроенного типа могут быть продвинуты во внешний тип только если имя не конфликтует с членом внешнего типа. В данном примере Base.Work потенциально продвигается в S, но объявленное поле S.Work занимает это имя на уровне S.

Следовательно, для проверки интерфейса компилятор видит у S поле Work, а не метод Work. Поле нельзя использовать как реализацию метода интерфейса, даже если его тип — например, func().

package main

type Worker interface { Work() }
type Base struct{}
func (Base) Work() {}

type S struct {
	Base
	Work int
}

func main() {
	var s S
	_ = s.Work       // обращение к полю
	// var w Worker = s // ошибка: Work — поле, а не метод
}

Нельзя исправить ситуацию явным вызовом s.Base.Work() и ожидать, что S начнёт реализовывать интерфейс: наличие доступного метода через отдельное поле не меняет методный набор S. Практические варианты — переименовать поле, переименовать метод встроенного типа или использовать другой тип-обёртку с явным методом.

Ситуация из практики

Допустим, Base содержит поведение обработчика, а в S хотят добавить поле Work для хранения числового идентификатора. После этого код, ранее принимавший S как Worker, перестаёт компилироваться.

Переименование поля обычно является лучшим решением: оно сохраняет интерфейсный контракт и не добавляет адаптеров. Обёртка с явным методом полезна, если имена менять нельзя, но она увеличивает объём кода и может потребовать явной передачи состояния. Удаление встраивания и делегирование дают наиболее явный дизайн, однако теряют удобство автоматического продвижения методов.

Выбор зависит от публичности типа. Для внутреннего типа проще переименовать конфликтующий член; для стабильного публичного API безопаснее ввести отдельный адаптер и не менять уже используемые имена без проверки всех интерфейсных контрактов.

Что кандидаты часто упускают

1. Вопрос: Если заменить Work int на Work func(), начнёт ли S реализовывать Worker?

   Ответ: Нет. Для интерфейса требуется метод с сигнатурой Work(), а поле, даже имеющее тип функции, методом не является. Вызов поля и вызов метода — разные языковые механизмы, поэтому тип поля не влияет на удовлетворение интерфейсу.

2. Вопрос: Поможет ли объявление var _ Worker = &S{} вместо var _ Worker = S{}?

   Ответ: Нет. Указатель *S может получить дополнительные методы через методный набор указателя и также может наследовать методы встроенного типа, но конфликт с одноимённым полем остаётся. Имя Work по-прежнему разрешается как поле S.Work, поэтому *S также не реализует Worker.

3. Вопрос: Можно ли добавить в S метод Work, не меняя поле с таким именем?

   Ответ: Нет. В одном типе нельзя объявить поле и метод с одинаковым именем. Поэтому прямой способ восстановить контракт невозможен: нужно переименовать поле или изменить структуру типов. Если исходный тип менять нельзя, применяют внешний адаптер, например отдельный тип с полем S и методом Work, делегирующим вызов в S.Base.Work().