Dal*_*ale 15 naming interface naming-conventions go
我只是发布我的代码:
/*
* 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
}
Run Code Online (Sandbox Code Playgroud)
应该注意的是,ServerSession也是一个接口,调用"ServerSessioner"对我来说感觉很难受.
我正在尝试使用IsRole()和AssumeRole()创建一个接口,但"Roler"似乎非常不稳定.我突然意识到,除了标准的"呃"后缀之外,我真的不知道或者曾经遇到过接口的命名约定.我似乎记得VS C++的惯例就是在所有内容之前抛出一个"我".这是"惯用语"吗?
有什么建议?
icz*_*cza 29
在你的情况我也只是他们的名字RoleChecker和RoleAssumer中,"合并"一个RoleCheckerAssumer.或者,如果您使用单个界面,那可能是RoleHelper或RoleChecker.
ServerSession也很好,甚至只是Session(特别是如果没有"客户"会话).ServerSessioner另一方面是坏的,Session不是动词而不是界面的方法.
关于这些公约的帖子很多.
按照惯例,一个方法接口由该方法name加上后缀-er或类似的修改命名构建的试剂名:
Reader,Writer,Formatter,CloseNotifier等.有许多这样的名称,它们很有价值,以及它们捕获的功能名称.
Read,Write,Close,Flush,String等有规范签名和意义.为避免混淆,请不要将您的方法作为其中一个名称,除非它具有相同的签名和含义.相反,如果您的类型实现的方法与众所周知类型的方法具有相同的含义,请为其指定相同的名称和签名;String不要调用你的字符串转换器方法ToString.
仅指定一个方法的接口通常只是附加了"er"的函数名称.
Run Code Online (Sandbox Code Playgroud)type Reader interface { Read(p []byte) (n int, err error) }有时结果不是正确的英语,但我们仍然这样做:
Run Code Online (Sandbox Code Playgroud)type Execer interface { Exec(query string, args []Value) (Result, error) }有时我们使用英语使其更好:
Run Code Online (Sandbox Code Playgroud)type ByteReader interface { ReadByte() (c byte, err error) }当接口包含多个方法时,请选择准确描述其用途的名称(示例:net.Conn,http.ResponseWriter,io.ReadWriter).
对于接收器的名称,不使用this或self或类似的.代替:
接收者是一种特殊的论点.
按照惯例,它们是反映接收器类型的一个或两个字符,因为它们通常出现在几乎每一行上:
Run Code Online (Sandbox Code Playgroud)func (b *Buffer) Read(p []byte) (n int, err error) func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) func (r Rectangle) Size() Point接收者名称在类型的方法中应该是一致的.(不要在一种方法中使用r而在另一种方法中使用rdr.)
方法接收者的名字应该反映其身份; 通常,其类型的一个或两个字母缩写就足够了(例如"客户"的"c"或"cl").不要使用通用名称,例如"me","this"或"self",这是面向对象语言的典型标识符,它们更强调方法而不是函数.名称不必像方法论证那样具有描述性,因为它的作用是显而易见的,不起任何文件目的.它可以很短,因为它几乎出现在每种类型的每个方法的每一行上; 熟悉承认简洁.也要保持一致:如果你用一种方法调用接收器"c",不要把它称为"cl".
我明白了,事实证明我可以使用“呃”约定。
/*
* 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
}
Run Code Online (Sandbox Code Playgroud)
谢谢 Sarathsp 让我正确思考这个问题。