![](https://habrastorage.org/getpro/habr/upload_files/5da/030/20c/5da03020cf1e9181d10393fc7170578d.png)
Первый очерк из цикла приключений в мире сусликов.
С этой статьи начинается серия небольших рассказов о необычных подводных камнях, которые можно встретить в начале разработки на Go. В статьях будут примеры кода, будьте с ними аккуратнее - не все из них будут компилироваться и работать, читайте внимательно комментарии, везде будет указано, на какой строке происходит ошибка. Также в блоках кода везде табуляция заменена на пробелы - это сделано намеренно, чтобы статьи выглядели у всех одинаково.
Начинать рассказывать я буду издалека, с самых основ, но это необходимо для полного понимания. В конце же рассказа, будет самое интересное, но всё равно стоит читать его с самого начала.
Пара слов обо мне. Я всю жизнь занимаюсь разработкой программного обеспечения, в основном в сфере WEB, успел познакомиться с многими языками программирования и поработать в разных крупных компаниях. Сейчас руковожу разработкой в компании NUT.Tech, мы там делаем классные и интересные вещи. В данный момент в основном разработка в отделе построена вокруг Go, поэтому о нём я вам и расскажу.
Статьи серии:
Интерфейсы в Go - как красиво выстрелить себе в ногу
...
Пожалуй, начнём. Вы когда-нибудь задумывались, что такое interface
? Ну, то есть, не ключевое слово синтаксиса, а что это такое в рантайме? Как выглядит его проинстанцированный объект? А, главное, каким свойством обладает при сравнении с nil
? Нет? Тогда устраивайтесь поудобнее, я сейчас вам всё расскажу.
Начнём с определения интерфейса из спецификации языка:
An interface type specifies a method set called its interface. A variable of interface type can store a value of any type with a method set that is any superset of the interface. Such a type is said to implement the interface. The value of an uninitialized variable of interface type is
nil
.
Мой вольный перевод:
Тип интерфейса определяет множество методов, называющееся интерфейс. Переменная типа интерфейса может хранить значение любого типа с набором методов, который является любым надмножеством интерфейса. Говорят, что такой тип реализует интерфейс. Значение неинициализированной переменной типа интерфейса равно
nil
.
На мой взгляд, хорошее абстрактное описание, которое не очень сильно помогает осознать интерфейсы на практике, но в целом даёт общее понимание. Очень советую пойти в документации в раздел Interface_types - там много примеров и более подробное описание.
Но этого поста бы не было, будь там вся необходимая информация ;) Допустим, мы уже понимаем, что переменная с интерфейсом в качестве типа это некий объект, который с точки зрения типизации обязан обладать всеми перечисленными в указанном интерфейсе методами.
Необходимо также понимать, что переменные с интерфейсом в качестве типа бессмысленны сами по себе, они не создаются и не используются в отрыве от обычных типов. И именно переменные обычных типов, превращаются в переменные интерфейсного типа. А с точки зрения компилятора в переменную интерфейсного типа может превратится любая переменная обычного типа, у которой её тип содержит все заявленные в интерфейсе методы. Хотя могут быть и дополнительные методы - реализация интерфейса от этого не сломается. Понимаю, всё несколько сложно и запутано, но дальше будут примеры и станет понятнее.
А что происходит, например, когда мы переменную определенного, конкретного типа, превращаем в другую переменную с интерфейсным типом? В Golang, как впрочем и многих других статически типизированных языках, у переменной можно легально получить доступ только к тем атрибутам и методам, которые существуют у типа этой переменной. В случае преобразования переменная получает определенный интерфейсный тип. Одна из очевидных проблем, которую мы встречаем, - потеря доступа ко всем атрибутам нашего конкретного типа и к его методам, которые не были указаны в интерфейсе.
Посмотрим на конкретном примере:
package main
import (
"fmt"
"reflect"
)
// создадим некоторый тип Человек,
// который умеет спать, есть и работать
type Man struct{}
func (m Man) Sleep() {}
func (m Man) Eat() {}
func (m Man) Work() {}
// и тип Пёс, который у нас умеет только лаять
type Dog struct{}
func (d Dog) Bark() {}
// теперь мы хотим понять, кто может стать программистом,
// для этого мы определяем интерфейс Programmer,
// и определяем в нём метод Work
// этим мы ограничиваем количество объектов,
// которые смогут быть программистами
// так случилось, что в нашем коде, чтобы стать программистом,
// достаточно уметь работать :)
type Programmer interface {
Work()
}
func main() {
// итак, теперь посмотрим, как работать с нашими типами и интерфейсом
// для начала создадим некоторого конкретного человека
Vasiliy := Man{}
// и посмотрим на его тип
fmt.Printf("%s\n", reflect.TypeOf(Vasiliy).String()) // main.Man
// также создадим Василию верного друга
Sharik := Dog{}
fmt.Printf("%s\n", reflect.TypeOf(Sharik).String()) // main.Dog
// что ж, теперь нужно проверить, кто же,
// Шарик или Василий нам лучше подойдёт на роль программиста
// для этого создадим абстрактного работника с типом Programmer
// и попробуем к нему присвоить наши объекты
var worker Programmer
worker = Sharik
// увы, этот код не будет скомпилирован,
// компилятор выведет следующую ошибку
// cannot use Sharik (type Dog) as type Programmer in assignment:
// Dog does not implement Programmer (missing Work method)
// теперь мы знаем, Шарик пока не может быть программистом,
// придётся им стать Василию
worker = Vasiliy // этот код компилируется и работает
// в целом, этого достаточно для базового понимания интерфейсов,
// но дальше будет ещё кое-что интересное
// проверим тип нашего работника теперь
fmt.Printf("%s\n", reflect.TypeOf(worker).String()) // main.Man
// в целом выглядит логично: мы сказали,
// что работником будет Василий, у которого тип Man,
// но раз уж так, давайте попробуем вызвать
// метод Sleep у нашего работника
worker.Sleep()
// worker.Sleep undefined (type Programmer has no field or method Sleep)
// увы, этот код не будет работать,
// так как на самом деле worker != Vasiliy
// типом переменной worker является интерфейс Programmer,
// который не содержит метод Sleep()
}
Что же происходит, и почему пакет reflect определяет тип нашего воркера как Man
, которым на самом деле он не является? Чтобы это понять, нужно погрузиться в недра исходного кода нашего "суслика" и посмотреть, чем представлен там тип interface
:
// https://golang.org/src/runtime/runtime2.go
type iface struct {
tab *itab
data unsafe.Pointer
}
Если не вдаваться в подробности, то в поле tab
у нас хранится информация о конкретном типе объекта, который был преобразован в интерфейс. А в поле data
- ссылка на реальную область памяти, в которой лежат данные изначального объекта, в нашем случае Василия. Поэтому библиотека reflect, когда хочет получить настоящий исходный тип объекта интерфейса, идёт в это поле tab
и получает информацию о типе там.
У нас остаётся возможность преобразовать наш объект интерфейса обратно к исходному типу, для этого у нас есть синтаксис утверждений типа, выглядит он следующим образом:
m, ok := worker.(Man)
fmt.Printf("%#v\n", m) // main.Man{}
fmt.Printf("%t\n", ok) // true
Можно использовать и без переменной ok
, но в таком случае Вы получите панику, если в интерфейсе окажется несоответствующий тип.
Окей, с этим вроде разобрались, идём дальше.
Как нам говорит документация: The value of an uninitialized variable of interface type is nil
. То есть наша переменная интерфейсного типа может принимать nil
. Ну это же супер! Если отмотать немного назад, то можно увидеть, как мы изначально инициализировали нашего работника - var worker Programmer
. Если верить документации, то в этот момент наш worker
был равен nil
. Доверяй, но проверяй:
func main() {
var worker Programmer
fmt.Printf("%#v\n", reflect.TypeOf(worker)) // <nil>
// и так, тут уже тип нашего воркера не main.Man,
// как это было при присвоении туда Василия, а nil
// ну хорошо, давайте ещё сделаем проверку,
// действительно ли наш пустой работник равен nil
fmt.Printf("%t\n", worker == nil) // true
// отлично, и правда nil
}
Но мы пойдём дальше: а что если попробовать создать пустую переменную типа *Man
и преобразовать её к интерфейсу? Пробуем:
func main() {
var man *Man
fmt.Printf("%#v\n", man) // (*main.Man)(nil)
var worker Programmer
fmt.Printf("%#v\n", worker) // <nil>
worker = man
fmt.Printf("%#v\n", worker) // (*main.Man)(nil)
// наш воркер изменил тип, он больше не совсем nil,
// а nil от типа *main.Man
// что же это для нас значит, давайте смотреть
fmt.Printf("%t\n", man == nil) // true
// отлично, наш man равен nil,
// мы же туда ничего не положили и ссылка равна nil
fmt.Printf("%t\n", worker == man) // true
// ну тоже хорошо, мы положили в переменную
// worker переменную man,
// и как мы уже убеждались ранее, они равны
// ну и понятно, по законам математики,
// если x = 0, а y = x, значит y = 0
fmt.Printf("%t\n", worker == nil) // false
// а вот и нет, это вам Go, а не математика
}
Давайте разбираться, почему так происходит. Как я уже говорил, объект интерфейса в Go содержит два поля: tab
с информацией о конкретном типе и data
, где лежит ссылка на сами данные. И вот, по правилам Go, интерфейс может быть равен nil
только если оба этих поля не определены.
Давайте смотреть, что у нас получается, когда мы преобразуем переменную man
в интерфейс:
func main() {
var worker Programmer
fmt.Printf("%s\n", reflect.ValueOf(worker)) // <invalid reflect.Value>
// рефлект не может получить значение из переменной worker,
// потому что его просто нет,
// то есть поле `data` у нашего интерфейса не задано
fmt.Printf("%v\n", reflect.TypeOf(worker)) // <nil>
// как не может получить и тип,
// так как он тоже не задан в поле `tab`
fmt.Printf("%t\n", worker == nil) // true
// worker равен nil
var man *Man
fmt.Printf("%t\n", man == nil) // true
// переменная man равняется nil
worker = man
fmt.Printf("%s\n", reflect.ValueOf(worker).Elem())
// <invalid reflect.Value>
// после присвоения переменной worker переменной man
// мы точно также не можем получить значение через reflect
// так как man у нас не содержит каких-либо данных, он равен `nil`
fmt.Printf("%v\n", reflect.TypeOf(worker)) // *main.Man
// а вот с типом интереснее мы из переменной worker
// получили тип переменной man, то есть *main.Man
// соответственно поле `tab` у нашего интерфейса уже явно не пустое
// и поэтому переменная worker больше не будет равна nil
fmt.Printf("%t\n", worker == nil) // false
}
Как итог, мы имеем интерфейс с заполненным полем tab
, и проверка на равенство с nil
всегда будет возвращать false
. Несмотря на то, что изначально переменная возвращала true
при сравнении с nil
.
Описано ли это поведение в документации к нашему суслику? - Нет. Ну точнее не совсем. В спецификации языка это не описано, но это есть в FAQ по языку: https://golang.org/doc/faq#nil_error. И там как раз рассмотрена одна из распространённых ошибок, связанная с этим поведением интерфейсов: когда мы из функции возвращаем ссылку на объект нашей кастомной ошибки. Данная ссылка, в свою очередь, может быть nil
, если ошибка в функции не произошла. И, когда происходит преобразование нашего объекта кастомной ошибки к интерфейсу error
, этот новый преобразованный объект уже никогда больше не будет равен nil
, и все проверки if err != nil {}
перестанут работать корректно.
Приведу пример чуть более подробный чем в faq:
package main
import "fmt"
// создаём свой собственный тип ошибки,
// обычно это бывает нужно чтобы передавать дополнительные данные
// вместе с ошибкой, так например сделано в библиотеке twirp
type CustomError struct{}
// этот метод нам нужен, чтобы реализовать интерфейс error
func (CustomError) Error() string { return "CustomError" }
// а в этой функции мы будем возвращать нашу ошибку, либо nil
func raiseError(raise bool) *CustomError {
if raise == true {
return &CustomError{}
}
return nil
}
func main() {
// для начала нам нужно инициализировать переменную,
// которая будет принимать результат из функции raiseError
var err error
// пробуем вернуть из нашей функции ошибку
err = raiseError(true)
fmt.Println(err != nil) // true
// отлично, err у нас действительно не равен nil
// а теперь вызовем функцию таким образом, чтобы она вернула nil
err = raiseError(false)
fmt.Println(err != nil) // true
// после преобразования в интерфейс, наш nil уже не очень то и nil
}
На этом мой очерк заканчивается, читайте о других интересных моментах из мира Go в следующих сериях и будьте аккуратны с интерфейсами.