В Go интерфейсы поведенческие. То есть они описывают то, что вещь делает больше, чем то, чем она является. Ваш пример выглядит так, как будто вы пытаетесь написать С# на Go с интенсивным использованием I перед классами интерфейса. Однако интерфейс, реализованный только одним типом, — пустая трата времени.
Вместо этого рассмотрите:
interface Deleteable { // You'd probably be tempted to call this IDeleteable
// Effective go suggests Deleter, but the grammar
// sounds weird
Delete() err
}
Теперь вы можете создать функцию для пакетного удаления:
func BatchDelete(victims []Deleteable) {
// Do some cool things for batching, connect to db, start a transaction
for _, victim := range(victims) {
victim.Delete() // Or arrange for this function to be called somehow.
}
}
Вероятно, вы бы быстрее приступили к работе, создав интерфейс для обновлений, сериализации и т. д., а также сохранив своих реальных пользователей/разрешения/и т. д. в конкретных структурах, реализующих эти методы. (Обратите внимание, что в Go вам не нужно говорить, что тип реализует интерфейс, это происходит «автоматически»). Вам также не обязательно иметь единый интерфейс для каждого метода (Updater, Serializable), но вы можете объединить их все в один интерфейс:
type DBObject interface {
Update()
Serialize() RowType
Delete()
}
type User struct {
Id int
Name string
// ... etc
}
Помните, что ваша модель всегда может «заполнить» объект пользователя для возврата из вашего API, даже если фактическое представление объекта пользователя является чем-то гораздо более расплывчатым, например. RDF тройки.
person
Danver Braganza
schedule
27.06.2015