Теория: Type assertion и type switch

В Go всё строится на интерфейсах. Интерфейс — это способ описать поведение без привязки к конкретной реализации. Такой подход даёт гибкость: функция может принимать любой тип, если он удовлетворяет интерфейсу. Но вместе с гибкостью приходит и неопределённость. Иногда важно понять, что именно лежит внутри интерфейса. Именно эту задачу решают type assertion и type switch.

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

func Log(v interface{}) {
	fmt.Println(v)
}

Такой код работает, но бесполезен, если нужно вести себя по-разному в зависимости от типа. Например, форматировать числа особым образом или показывать поля структуры. Без type assertion придётся вручную проверять каждый тип через — reflect. Это громоздко, небезопасно и плохо читается:

func Log(v interface{}) {
	rv := reflect.ValueOf(v)
	switch rv.Kind() {
	case reflect.Int:
		fmt.Printf("int: %d\n", rv.Int())
	case reflect.String:
		fmt.Printf("string: %s\n", rv.String())
	default:
		fmt.Println("something else")
	}
}

Такой способ работает, но требует много кода и плохо оптимизируется. Более того, при ошибке программа упадёт уже внутри reflect, и отладка может оказаться нетривиальной. Чтобы обойти эту сложность, в Go появился механизм type assertion.

Type assertion позволяет сказать: «Я уверен, что это значение такого-то типа». Если уверенность не стопроцентная — можно использовать безопасную форму с ok. Это в несколько раз проще, чем рефлексия.

func Log(v interface{}) {
	if s, ok := v.(string); ok {
		fmt.Println("строка:", s)
		return
	}
	if i, ok := v.(int); ok {
		fmt.Println("число:", i)
		return
	}
	fmt.Println("что-то ещё")
}

Эта конструкция работает с одним типом за раз. Если вариантов становится много — удобнее использовать type switch. Это синтаксическая конструкция, которая избавляет от повторяющихся проверок и делает код чище:

func Log(v interface{}) {
	switch val := v.(type) {
	case string:
		fmt.Println("строка:", val)
	case int:
		fmt.Println("число:", val)
	case bool:
		fmt.Println("логическое значение:", val)
	default:
		fmt.Println("неизвестный тип")
	}
}

Интерфейсы в Go позволяют описывать поведение через набор методов, не раскрывая конкретный тип. Это делает код гибким и расширяемым. Однако бывают ситуации, когда всё же нужно узнать, с каким именно типом мы имеем дело. Для этого в языке есть специальная конструкция — type switch.

Type switch работает только с интерфейсами. Он позволяет безопасно извлечь конкретный тип из интерфейсного значения и использовать его напрямую — без явного приведения и дополнительных проверок. Это может быть удобно, если одна и та же функция должна по-разному обрабатывать значения разных типов.

Пример:

func Describe(s Shape) {
	switch v := s.(type) {
	case Circle:
		fmt.Println("Круг с радиусом", v.Radius)
	case Rectangle:
		fmt.Println("Прямоугольник", v.Width, "на", v.Height)
	default:
		fmt.Println("Неизвестная фигура")
	}
}

Здесь интерфейс Shape скрывает конкретную реализацию. Чтобы получить доступ к полям Radius, Width и Height, приходится использовать type switch.

На практике такой подход встречается, например, при работе с интерфейсом error, который может быть реализован десятками разных типов ошибок. Иногда доступ к внутренней информации действительно необходим.

Но в прикладной разработке — особенно при проектировании интерфейсов — type switch часто сигнализирует о недоработке. Если функция должна вести себя по-разному в зависимости от типа, разумнее передать это поведение самим типам. Например, добавить метод String() к каждому типу, и описать, как он должен себя представить:

type Shape interface {
	Area() float64
	String() string
}

func Describe(s Shape) {
	fmt.Printf("%s, площадь %.2f\n", s, s.Area())
}

Теперь Describe не знает ничего о кругах или прямоугольниках. Всё, что ей нужно — это интерфейс Shape. Каждый тип сам отвечает за своё описание, и код остаётся простым и расширяемым.