Opzioni di pattern per Go Enum con denominazione di pacchetto / tipo succinta

Sfondo

Recentemente mi è stato affidato un progetto per sviluppare un piccolo servizio web che su richiesta HTTP interagisce con 2 API separate. Nel tentativo di mappare i tipi che stavo comunemente usando, mi sono trovato spesso di fronte a situazioni in cui non sembrava esserci una soluzione "pulita" per gestire la moltitudine di tipi Enum da queste API.

Attraverso un sacco di google e di sperimentazione, lo schema che meglio corrispondeva al titolo di questo post consisteva nella seguente brutta implementazione:

Struttura del progetto

(nomi API modificati per proteggere la privacy delle persone)

../
  |- McAPI/
  |   |- enums/
  |       |- GrillStatus
  |       |   |- enum.go
  |       |- BurgerStage
  |           |- enum.go
  |- APIBell/
      |- enums
          |- TortillaType
          |   |- enum.go
          |- BurritoShape
              |- enum.go

File Enum

(Sono consapevole che il formatter go potrebbe sanguinare dagli occhi se vedesse questo)

package GrillStatus

type Enum string

const(
  HEATED Enum = "grill_heated"
  OFF    Enum = "grill_off"
)

func Values() map[string]Enum {
  return map[string]Enum{
    string(HEATED): HEATED,
    string(OFF):    OFF,
  }
}

func(e *Enum) UnmarshalXML(...) error {...}

File consumato

(Non sono d'accordo con il formato standard di Go su quasi tutte le scelte di stile)

package somethingCompletelyDifferent

import "foo/bar/McApi/enums/GrillStatus"

type Grill struct {
  Status GrillStatus.Enum 'xml:"status,attr"'
  ...
}

func DoSomething(grill Grill) {
  switch grill.Status {
    case GrillStatus.HEATED:
      // do something
    case GrillStatus.OFF:
      // do something
  }
}

Ragionamento

Con la struttura di cui sopra sono stato in grado di raggiungere diversi obiettivi, principalmente:

1. Utilizza il nome del pacchetto per mantenere un contesto per le costanti
2. Consenti nomi più brevi di costanti individuali (enum)
3. Prevenire il disordine di qualsiasi pacchetto con dozzine di costanti
4. Permetti luoghi separati per implementare la logica specifica di enum a la Java

Domande

• Quali altri pattern ci sono là fuori per affrontare questo?

• Come qualcuno che viene da Java e probabilmente vedendo questo problema attraverso un obiettivo colorato di Java, esiste un approccio completamente diverso per queste situazioni? (Cercando di mappare enum esterni a valori Go utili / tipi / etc ...)

Altre note

Googling mi porta su blog e altri siti di scambio di stack, ma le risposte comuni forniscono ben poco lavoro per quanto riguarda il ragionamento o l'applicazione complessa di Enums. Piuttosto sembra che siano trattati come semplici costanti numeriche o di stringa piuttosto che come un tipo a se stessi.

Grazie!