Можно ли в Go объявить интерфейс с полями, как в Java/C#?

Короткий ответ: в Go интерфейсы не могут содержать поля

Это осознанное дизайнерское решение. В Go интерфейсы определяют только поведение (методы), а не состояние (поля). В отличие от Java или C#, где интерфейс может объявлять свойства, в Go действует принцип: «Интерфейс — это контракт на поведение, а не на данные».

Как решить вашу задачу: 4 правильных подхода

1. Использовать геттер-метод (самый идиоматичный способ)

Вместо поля объявите метод, возвращающий значение:

type Animal interface {
    Name() string
    Speak()
}

type Dog struct {
    name string
}

func (d Dog) Name() string {
    return d.name
}

func (d Dog) Speak() {
    fmt.Println("Woof!")
}

// Использование
var a Animal = Dog{name: "Rex"}
fmt.Println(a.Name()) // "Rex"

Это полностью решает проблему: любой тип, реализующий интерфейс, обязан предоставить метод Name(). При этом внутренняя реализация (поле, вычисление или внешний источник) остаётся скрытой.

2. Встраивание структуры (embedding) с интерфейсом

Если вам нужно гарантировать наличие поля на уровне компиляции, используйте композицию:

type Animal struct {
    Name string
}

type AnimalBehavior interface {
    Speak()
}

type Dog struct {
    Animal        // встраиваем структуру с полем
    AnimalBehavior // встраиваем интерфейс с поведением
}

func (d Dog) Speak() {
    fmt.Println("Woof!")
}

// Конструктор, гарантирующий заполнение поля
func NewDog(name string) Dog {
    return Dog{
        Animal: Animal{Name: name},
    }
}

Теперь любой Dog обязан иметь поле Name, потому что оно часть встроенной структуры Animal.

3. Дженерики (Go 1.18+) — для строгих контрактов на поля

Если вам критично проверять наличие поля на этапе компиляции, используйте параметризованные типы:

type HasName interface {
    ~struct{ Name string }
}

type NamedAnimal[T HasName] struct {
    Data T
}

func (n NamedAnimal[T]) GetName() string {
    return n.Data.Name
}

type Dog struct {
    Name string
}

func main() {
    dog := NamedAnimal[Dog]{Data: Dog{Name: "Rex"}}
    fmt.Println(dog.GetName())
}

Это продвинутый приём, но он даёт 100% гарантию, что тип имеет поле Name.

4. Проверка через рефлексию (runtime) — НЕ рекомендуется

Технически возможно, но это нарушает философию Go и снижает производительность:

func HasNameField(v interface{}) bool {
    t := reflect.TypeOf(v)
    if t.Kind() == reflect.Struct {
        _, ok := t.FieldByName("Name")
        return ok
    }
    return false
}

Почему в Go так сделали?

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

Итог: используйте метод-геттер (вариант 1) — это самый Go-way способ. Если вам критичен compile-time контроль поля — используйте дженерики (вариант 3).

type Speaker interface {
    Speak()
}

type Namer interface {
    Name() string
}

// Комбинируем интерфейсы при необходимости
type NamedSpeaker interface {
    Speaker
    Namer
}