web-dev-qa-db-fra.com

Convention de dénomination d'interface Golang

Je vais juste poster mon code:

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

Il convient de noter que ServerSession est également une interface, appeler "ServerSessioner" me semble un peu dérangeant.

Je joue avec l'idée de créer une interface avec IsRole () et AssumeRole (), mais "Roler" semble très bancal. Il me vient à l'esprit que je ne connais pas vraiment ou n'ai jamais rencontré de conventions de dénomination pour les interfaces, autres que le suffixe "er" standard. Il me semble que la convention VS C++ consiste à simplement lancer un "je" devant tout. Est-ce "idiomatique"?

Aucune suggestion?

gointerfacenaming-conventionsnaming
15
Dale

Je l'ai compris, je peux utiliser la convention "er".

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

Merci Sarathsp de m'avoir fait réfléchir correctement.

2
Dale

Dans votre cas, je les nommerais simplement RoleChecker et RoleAssumer, celui "fusionné" RoleCheckerAssumer. Ou si vous optez pour une seule interface, cela pourrait être RoleHelper ou RoleChecker.

ServerSession est également très bien, ou même simplement Session (surtout s'il n'y a pas de session "client"). ServerSessioner d'autre part est mauvais, Session n'est pas un verbe et pas une méthode de l'interface.

Il y a eu de nombreux articles sur les conventions.

Go efficace: noms d'interface:

Par convention, les interfaces à une méthode sont nommées par le nom de la méthode plus un suffixe -er ou une modification similaire pour construire un nom d'agent: Reader, Writer, Formatter, CloseNotifier etc.

Il existe un certain nombre de ces noms et il est productif de les honorer et les noms de fonction qu'ils capturent. Read, Write, Close, Flush, String et ainsi de suite ont des signatures et des significations canoniques. Pour éviter toute confusion, ne donnez pas à votre méthode l'un de ces noms à moins qu'elle ait la même signature et la même signification. Inversement, si votre type implémente une méthode ayant la même signification qu'une méthode sur un type connu, donnez-lui le même nom et la même signature; appelez votre méthode de conversion de chaîne String pas ToString.

Types d'interface @ Qu'y a-t-il dans un nom? - Pourparlers sur golang.org

Les interfaces qui spécifient une seule méthode ne sont généralement que le nom de la fonction avec 'er' ajouté.

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

Parfois, le résultat n'est pas correct en anglais, mais nous le faisons quand même:

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

Parfois, nous utilisons l'anglais pour le rendre plus agréable:

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

Lorsqu'une interface comprend plusieurs méthodes, choisissez un nom qui décrit précisément son objectif (exemples: net.Conn, http.ResponseWriter, io.ReadWriter).

Pour les noms de destinataires, n'utilisez pas this ou self ou des noms similaires. Au lieu:

Receivers @ Qu'y a-t-il dans un nom? - Pourparlers sur golang.org

Les récepteurs sont un type d'argument particulier.

Par convention, ce sont un ou deux caractères qui reflètent le type de récepteur, car ils apparaissent généralement sur presque toutes les lignes:

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

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

func (r Rectangle) Size() Point

Les noms des récepteurs doivent être cohérents dans toutes les méthodes d'un type. (N'utilisez pas r dans une méthode et rdr dans une autre.)

Commentaires sur la révision du code: noms des destinataires:

Le nom du récepteur d'une méthode doit refléter son identité; souvent une abréviation d'une ou deux lettres de son type suffit (comme "c" ou "cl" pour "Client"). N'utilisez pas de noms génériques tels que "moi", "ceci" ou "soi", identificateurs typiques des langages orientés objet qui mettent davantage l'accent sur les méthodes que sur les fonctions. Le nom n'a pas besoin d'être aussi descriptif que celui d'un argument de méthode, car son rôle est évident et ne sert à rien de documentaire. Il peut être très court car il apparaîtra sur presque toutes les lignes de chaque méthode du type; la familiarité admet la brièveté. Soyez également cohérent: si vous appelez le récepteur "c" dans une méthode, ne l'appelez pas "cl" dans une autre.

29
icza

Dans golang Par convention, les noms d'interface à une méthode sont des noms désignant l'auteur d'une action. Par exemple,

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

Il serait préférable de clarifier les spécificités de la convention, quelles qu'elles soient, ce qui fonctionne bien lorsqu'il n'y a qu'une seule fonction ou qu'un ensemble de fonctions très spécifique est requis par l'interface.

Il est courant d'utiliser le préfixe I pour le plus petit dénominateur commun des fonctions, dans ce cas IRole serait un meilleur nom d'interface car l'interface définit deux fonctions qui doivent être satisfaites par tous les types représentant Role

2
Sarath Sadasivan Pillai