Как правильнее хранить разные типы в одном поле структуры?

Question

[KirSupi]

Есть структуры User, Subscriber и Admin

type Admin struct {
	Permissions map[string]interface{}
}
type Subscriber struct {
	Online        bool
	Status        string
	SubscriptedTo []int
}
type User struct {
	ID    int
	Login string
	Role  string // "subscriber"/"admin"
	RoleModel ??? // здесь должен быть Admin{} или Subscriber{}
}

Как правильнее в User.RoleModel в зависимости от роли записать структуру Admin или Subscriber? Если делать через пустой интерфейс, то потом постоянно надо прогонять его через mapstructure.Decode
Может, есть какие-то идеи как подобную задачу решить иначе?

Comments

[Александр Павлюк]

Это все структуры внутренней модели или вопрос про то, как это все дело маршалить в json?

[KirSupi]

Александр Павлюк, с json'ом проблем нет. Вопрос именно в том, как хранить две разные структуры в одном поле User.RoleModel

[Александр Павлюк]

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

[KirSupi]

Александр Павлюк, как раз Subscriber и Admin вообще себя никак не ведут, они просто хранят данные в полях

[Александр Павлюк]

KirSupi, тогда не очень ясно, зачем делать это двумя разными структурами в одном поле. Под поведением в данном случае может подразумеваться способность этих объектов по вызову их методов отдавать какую-то информацию.

Answer 1

[uvelichitel]

Мне кажется вы с ног на голову... Может быть так?

type Admin struct {
  Permissions map[string]interface{}
  User
}
type Subscriber struct {
  Online        bool
  Status        string
  SubscriptedTo []int
  User
}
type User struct {
  ID    int
  Login string
}

Answer 2

[Степан И]

Для перечисления типа можно использовать типизированные константы.

const (
	NewUserType  userType = "NEW"
	AdminType  userType = "ADMIN"
)

type User struct {
  ID    int
  Login string
  Type userType
}

Хотя для конкретного кейса это не подходит. Тут лучше применить RBAC.