Schnittstelle Namenskonvention Golang

Question

Ich werde einfach meinen Code schreiben:

/* 
* Role will ALWAYS reserve the session key "role". 
*/ 
package goserver 

const (
    ROLE_KEY string = "role" 
) 

type Role string 

//if index is higher or equal than role, will pass 
type RolesHierarchy []Role 

func (r Role) String() string { 
    return string(r) 
} 

func NewRole(session ServerSession) Role { 
    return session.GetValue(ROLE_KEY).(Role) 
} 

func (this Role) IsRole(role Role, hierarchy RolesHierarchy) bool { 
    if role == this { 
     return true 
    } 
    if len(hierarchy) == 0 { 
     return false 
    } 
    var thisI int = 0 
    var roleI int = 0 
    //Duped roles in hierarchy are verified in verifyConfig during parse 
    for i, r := range hierarchy { 
     if this == r { 
      thisI = i 
     } 
     if role == r { 
      roleI = i 
     } 
    } 
    //TODO I can probably condense what follows into one if 
    if thisI == 0 && roleI == 0 { 
     return false 
    } 
    return thisI >= roleI 
} 

func (this *Role) AssumeRole(session ServerSession, role Role) { 
    session.SetValue(ROLE_KEY, role) 
    *this = role 
} 

Es sollte angemerkt werden, dass Serversession ist auch eine Schnittstelle, ruft „ServerSessioner“ fühlt sich einfach wackelig zu mir.

Ich spiele mit der Idee, eine Schnittstelle mit IsRole() und AssumeRole() zu erstellen, aber "Roler" scheint sehr wackelig. Es dämmert mir, dass ich wirklich keine Namenskonventionen für Schnittstellen kenne oder jemals zuvor gefunden habe, abgesehen von dem Standard-Suffix "er". Ich erinnere mich, dass die VS C++ - Konvention einfach ein "Ich" vor alles wirft. Ist das "idiomatisch"?

Irgendwelche Vorschläge?

Answer 1

Ich habe es, tur ns out kann ich die "er" Konvention verwenden.

/* 
* Role will ALWAYS reserve the session key "role". 
*/ 
package goserver 

const (
    ROLE_KEY string = "role" 
) 

type Role string 

//if index is higher or equal than role, will pass 
type RolesHierarchy []Role 

type RoleChecker interface { 
    IsRole(Role, RolesHierarchy) bool 
} 

type RoleAssumer interface { 
    AssumeRole(ServerSession, Role) 
} 

type RoleCheckerAssumer interface { 
    RoleChecker 
    RoleAssumer 
} 

func (r Role) String() string { 
    return string(r) 
} 

func NewRole(session ServerSession) Role { 
    return session.GetValue(ROLE_KEY).(Role) 
} 

func (this Role) IsRole(role Role, hierarchy RolesHierarchy) bool { 
    if role == this { 
     return true 
    } 
    if len(hierarchy) == 0 { 
     return false 
    } 
    var thisI int = 0 
    var roleI int = 0 
    //Duped roles in hierarchy are verified in verifyConfig during parse 
    for i, r := range hierarchy { 
     if this == r { 
      thisI = i 
     } 
     if role == r { 
      roleI = i 
     } 
    } 
    //TODO I can probably condense what follows into one if 
    if thisI == 0 && roleI == 0 { 
     return false 
    } 
    return thisI >= roleI 
} 

func (this *Role) AssumeRole(session ServerSession, role Role) { 
    session.SetValue(ROLE_KEY, role) 
    *this = role 
} 

Danke Sarathsp dafür, dass ich darüber richtig nachgedacht habe.

Answer 2

In Golang Per Konvention sind One-Method-Interface-Namen Substantive, die den Handelnden einer Aktion bezeichnen. Zum Beispiel wäre

the `Read` method implements the `Reader` interface, and 
the `Generate` method implements the `Generator` interface. 

Es ist am besten, die Besonderheiten der Konvention deutlich zu machen, unabhängig davon, was sie are.This geht gut, wenn es nur eine Funktion oder eine Reihe von sehr spezifischen Funktionen erforderlich sind, durch die Schnittstelle

Es ist eine Praxis, I Präfix kleinsten gemeinsamen Nenners der Funktionen verwenden, in diesem Fall IRole wäre eine bessere Schnittstelle Name sein, da die Schnittstelle zwei Funktionen definiert, die von allen Typen werden satiisfied hat zu repräsentieren Role

Answer 3

In Ihrem Fall würde ich sie nur RoleChecker und , die "fusionierte" one RoleCheckerAssumer nennen. Oder wenn Sie mit einer einzigen Schnittstelle gehen würden, könnte das RoleHelper oder RoleChecker sein.

ServerSession ist auch in Ordnung, oder auch nur Session (vor allem, wenn es keine "Client" -Sitzung gibt). ServerSessioner auf der anderen Seite ist schlecht, Session ist kein Verb und keine Methode der Schnittstelle.

---

Es gab viele Beiträge über die Konventionen.

Effective Go: Interface names:

Vereinbarungsgemäß wird ein Verfahren Schnittstellen, die von dem Methodennamen zuzüglich einer -en Suffix oder ähnliche Modifikation genannt, ein Mittel f zu konstruieren: Reader, Writer, Formatter, CloseNotifier usw.

Es gibt eine Reihe solcher Namen und es ist produktiv, sie und die Funktionsnamen, die sie erfassen, zu beachten. Read, Write, Close, Flush, String und so weiter haben kanonische Signaturen und Bedeutungen. Um Verwechslungen zu vermeiden, geben Sie Ihrer Methode keinen Namen, es sei denn, sie hat die gleiche Signatur und Bedeutung.Umgekehrt, wenn Ihr Typ eine Methode mit der gleichen Bedeutung wie eine Methode eines bekannten Typs implementiert, geben Sie ihm denselben Namen und dieselbe Signatur; Rufen Sie Ihre String-Konverter-Methode String nicht ToString.

Interface Types @ What's in a name? - Talks at golang.org

Schnittstellen, die nur eine Methode angegeben sind in der Regel nur, dass Funktionsnamen mit ‚ER‘, um es angehängt.

type Reader interface { 
    Read(p []byte) (n int, err error) 
} 

Manchmal ist das Ergebnis Englisch nicht richtig, aber wir tun es trotzdem:

type Execer interface { 
    Exec(query string, args []Value) (Result, error) 
} 

Manchmal verwenden wir Englisch es schöner zu machen:

type ByteReader interface { 
    ReadByte() (c byte, err error) 
} 

Wenn eine Schnittstelle mehrere enthält Methoden, wählen Sie einen Namen, der seinen Zweck genau beschreibt (Beispiele: net.Conn, http.ResponseWriter, io.ReadWriter).

Für Empfänger Namen, verwenden Sie nicht this oder self oder ähnliche. Statt dessen:

Receivers @ What's in a name? - Talks at golang.org

Receiver sind eine besondere Art von Argument.

Vereinbarungs sie sind ein oder zwei Zeichen, die den Empfängertyp zu reflektieren, weil sie in der Regel auf fast jeder Zeile erscheinen:

func (b *Buffer) Read(p []byte) (n int, err error) 

func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) 

func (r Rectangle) Size() Point 

Empfängernamen über eine Art Methoden konsistent sein sollte. (nicht r in einem Verfahren und rdr in ein anderes verwenden.)

Go Code Review Comments: Receiver Names:

Der Name eines Empfängers Methode sollte ein Spiegelbild seiner Identität sein; oft genügt eine ein- oder zweistellige Abkürzung seines Typs (zB "c" oder "cl" für "Client"). Verwenden Sie keine generischen Namen wie "Ich", "Dies" oder "Selbst", die für objektorientierte Sprachen typisch sind, die mehr Wert auf Methoden als auf Funktionen legen. Der Name muss nicht so beschreibend sein wie der eines Methodenarguments, da seine Rolle offensichtlich ist und keinem dokumentarischen Zweck dient. Es kann sehr kurz sein, da es auf fast jeder Linie jeder Methode des Typs erscheint; Vertrautheit gibt Kürze zu. Seien Sie auch konsistent: Wenn Sie den Empfänger in einer Methode "c" nennen, nennen Sie ihn in einer anderen nicht "cl".