2016-08-09 43 views
4

Ich werde einfach meinen Code schreiben:Schnittstelle Namenskonvention Golang

/* 
* 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?

+1

Ich würde es nur 'RoleSupport' nennen, aber das Erreichen von English.SE wäre in der Tat ein interessantes Unterfangen. Bitte denken Sie daran, 'this' nicht zu verwenden, um Methodenempfänger zu benennen: Dies ist als unidiomatisches Go verpönt. [Ein Beispiel] (http://stackoverflow.com/q/23482068/720999) über diese Angelegenheiten zu diskutieren. – kostix

+0

Ja, ich habe mit Empfängernamen gekämpft. Ich weiß, dass die Go-Idiom ist, einzelne Buchstaben Variablen zu verwenden .... Es tut mir leid, ich kann das nicht tun. "Dies" oder "Selbst" ist in jeder anderen Sprache so weit verbreitet, dass es die Bedeutung eindeutig definiert. "RoleSupport" ist in Ordnung, passt aber nicht zu einem ordentlichen Muster. – Dale

+1

Nicht einzelne Buchstaben, sondern aussagekräftige Abkürzungen - mit einzelnen Buchstaben, die für kurze Funktionen OK sind (Ihre eingeschlossen). "Jede andere Sprache" ist sicher eine grobe Übertreibung.Aus irgendeinem Grund ist das kein Problem für mich: verschiedene Sprachen * fühlen * anders. Anfänger-Programmierer versuchen wirklich, Trick-Hunde zu sein, die versuchen, ihre erlernten Fähigkeiten in jede neue Sprache zu tragen, der sie gegenüberstehen (da waren sie selbst), aber es ist immer besser, die Philosophie hinter der Sprache zu verstehen und dabei zu bleiben. – kostix

Antwort

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.

1

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

+0

IsRoler und AssumeRoler -> IsserAssumer? lol, das könnte im englischen stack exchange besser sein .... – Dale

+0

@Dale https://talks.golang.org/2014/names.slide#14 => Manchmal ist das Ergebnis nicht korrekt Englisch, aber wir machen es trotzdem: –

10

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".

+0

Single-Methode-Schnittstellen sind "einfacher". Das "Is ()" warf mich ab. Ich habe am Ende nur "checker()" verwendet. Ja, tut mir leid, ich werde keine ein- oder zweistelligen Bezeichner verwenden. Es ist mir egal, was hier idiomatisch ist. Ich kenne ein halbes Dutzend Sprachen, die dieses oder das selbe verwenden. Warum sollte ich die Konvention hier brechen, nur weil ein Dokument in einer Sprachspezifikation sagt, dass ich es sollte? Dies oder Selbst ist genau das, was ich meine und was ich will. Am Ende des Tages muss ich meinen Code lesen, und wenn ich meine Spaghetti nach einem einzelnen Buchstaben-Identifizierer stöbere, worum geht es dann? – Dale

+3

@Dale Du machst was du willst. Niemand wird dich zwingen, etwas zu tun. Und solange Sie "alleine" programmieren, wird es niemanden stören. Wenn Sie jedoch mit anderen zusammenarbeiten möchten oder andere mit Ihrem Code arbeiten müssen, müssen Sie eine "gemeinsame" Sprache sprechen. In Bezug auf 'this' und' self' als Methode receiver: [In Go nennt die Empfängervariable 'self' irreführende oder gute Praxis?] (Http://stackoverflow.com/questions/23482068/in-go-isnaming -die-Empfänger-Variable-Selbst-irreführende-oder-gute-Praxis) – icza

+0

Vielen Dank. Ich möchte nicht streitsüchtig sein. Ich plane, diesen Haufen zu beschaffen. Vielleicht zwingt mich Feedback dazu, meine Entscheidung zu überdenken. Ich bin immer noch nicht überzeugt von den Entscheidungen der Designer hier. Davon abgesehen, war alles, was ich in Go gesehen habe, sehr beeindruckend. – Dale