Соглашение об именах интерфейсов 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
}

Следует отметить, что ServerSession также является интерфейсом, вызывая «ServerSessioner» для меня, кажется, не совсем удачным.

Я играю над идеей создания интерфейса с IsRole () и AssumeRole (), однако «Roler» кажется очень вялым. Меня осенило, что я действительно не знаю или никогда не сталкивался с соглашениями об именах для интерфейсов, кроме стандартного суффикса "er". Кажется, я вспоминаю, что соглашение VS C ++ состоит в том, чтобы просто бросить «я» перед всем. Это "идиоматический"?

Какие-либо предложения?

 Dale09 авг. 2016 г., 08:27
Да, я боролся с именами получателей. Я знаю, что идиома go состоит в использовании однобуквенных переменных .... Извините, я не могу этого сделать. «это» или «я» настолько распространены в любом другом языке, что устраняет неоднозначность значения. "RoleSupport" в порядке, но не совсем подходит для аккуратного шаблона.
 kostix09 авг. 2016 г., 10:09
По крайней мере, это снижает коэффициент WTF для следующего программиста, имеющего дело с вашим кодом. ;-)
 kostix09 авг. 2016 г., 08:21
Я бы просто назвал этоRoleSupport но достижение английского. SE было бы действительно интересным делом. Пожалуйста, не используйтеthis назвать получателей метода: это осуждается как однотипный Go.Один пример обсуждать эти вопросы.
 Dale09 авг. 2016 г., 10:53
Фактор WTF, «это» или «я» является «идиоматическим» по крайней мере на полдюжине языков, которые я «знаю»
 Dale11 авг. 2016 г., 07:11
Я реорганизовал этот проект, чтобы не включать это или себя.play.golang.org/p/hGDELp3OBA это довольно круто IIRC первым, что помещено в стек при вызове функции в C ++, является ссылка на this, за которой следуют параметры функции. «это» можно рассматривать как неявный первый параметр, я рад, что это происходит здесь. Это мало чем отличается от python, где они просто удалили неявную часть. Я до сих пор не совсем убежден, учитывая то, что я знаю до сих пор, но я в неведении, поэтому я пойду.
 kostix09 авг. 2016 г., 10:09
Не отдельные буквы, а скорее значимые сокращения - с единственными буквами, которые подходят для коротких функций (включая ваши). «Любой другой язык», безусловно, является грубым преувеличением. Ну почему-то для меня это не проблема: разные языки простоЧувствовать по-другому. Программисты-новички действительно стараются быть хитрыми собаками, пытаясь перенести свой набор выученных навыков на любой новый язык, с которым они сталкиваются (я был там сам), но всегда лучше понять философию языка и придерживаться его.

Ответы на вопрос(3)

Решение Вопроса

Я понял, оказывается, я могу использовать "эр" соглашение.

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

Спасибо, Саратсп, за то, что я правильно об этом подумал.

В golang По соглашению имена интерфейсов с одним методом - это существительные, обозначающие исполнителя действия. Например,

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

Лучше всего прояснить специфику соглашения, независимо от того, чем они являются. Это хорошо, когда существует только одна функция или для интерфейса требуется очень специфический набор функций.

Есть практика использованияI префикс к наименьшему общему знаменателю функций, в данном случаеIRole было бы лучшим именем интерфейса, так как интерфейс определяет две функции, которые должны удовлетворять все типы, представляющиеRole

 Sarath Sadasivan Pillai27 янв. 2017 г., 04:01
@Долtalks.golang.org/2014/names.slide#14  => Иногда результат не правильный английский, но мы все равно делаем это:
 Sarath Sadasivan Pillai26 июл. 2018 г., 02:44
Имя интерфейса @Victor зависит от функций, которые он реализует
 Dale09 авг. 2016 г., 08:01
IsRoler и AssumeRoler -> IsserAssumer? LOL, это может быть лучше в обмене английских стека ....
 Victor25 июл. 2018 г., 00:27
@SarathSadasivanPillai .. позвольте мне попытаться понять ... если я привнесу в этот контекст структуру (то есть структуру данных, связанную с методом), я бы скорее сказал «любая структура, реализующая метод« Чтение », становится читателем ", что имеет смысл ?; Позвольте мне добавить еще один быстрый вопрос: как называется структура, используемая в качестве источника чтения? «Sourcer» ??, (я знаю, что это будет «читабельно» на Java!)
 Victor27 июл. 2018 г., 15:46
@SarathSadasivanPillai, я думаю, я понял. Смысл в том, что по какой-то причине мой ум на основе ОО (после нескольких лет в JAVA) все еще заставляет меня говорить, что интерфейсы описывают поведение объектов (одного и того же типа), а интерфейсы в go также описывают поведение объектов. Оба способа предназначены для описания методов (1 или многие) с объектом, мы согласны с этим? Угадай, в JAVA ты ищешьслово описание того, что клиент может сделать с объектом (вещи, которые объект может «сказать» сделать), и в GOLANG слово относится исключительно к тому, что объект может сделать. Это устремило меня к вопросу об Sourcer / Readable.

В вашем случае я бы просто назвал ихRoleChecker а такжеRoleAssumer«слитый»RoleCheckerAssumer, Или, если бы вы пошли с одним интерфейсом, это может бытьRoleHelper или жеRoleChecker.

ServerSession тоже хорошо, или даже простоSession (особенно если нет «клиентской» сессии).ServerSessioner с другой стороны это плохо,Session это не глагол и не метод интерфейса.

Там было много сообщений о конвенциях.

Effective Go: имена интерфейсов:

По соглашению интерфейсы с одним методом именуются именем метода плюс суффикс -er или аналогичная модификация для создания существительного агента:Reader, Writer, Formatter, CloseNotifier и т.п.

Есть несколько таких имен, и полезно почитать их и имена функций, которые они записывают.Read, Write, Close, Flush, String и так далее имеют канонические подписи и значения. Чтобы избежать путаницы, не называйте свой метод одним из этих имен, если он не имеет одинаковую подпись и значение. И наоборот, если ваш тип реализует метод с тем же значением, что и метод для известного типа, присвойте ему то же имя и сигнатуру; вызовите ваш метод преобразования строкString неToString.

Типы интерфейса @ Что в имени? - Разговоры на golang.org

Интерфейсы, которые определяют только один метод, обычно представляют собой просто имя функции с добавленным к нему 'er'.

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

Иногда результат не правильный английский, но мы все равно делаем это:

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

Иногда мы используем английский, чтобы сделать его лучше:

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

Если интерфейс включает несколько методов, выберите имя, которое точно описывает его назначение (примеры: net.Conn, http.ResponseWriter, io.ReadWriter).

Для имен получателей не используйтеthis или жеself или похожие. Вместо:

Приемники @ Что в имени? - Разговоры на golang.org

Приемники - это особый аргумент.

По соглашению это один или два символа, которые отражают тип получателя, потому что они обычно появляются почти в каждой строке:

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 в другом.)

Go Code Review Комментарии: имена получателей:

Имя получателя метода должно отражать его идентичность; часто достаточно одной или двух буквенных аббревиатур этого типа (например, «c» или «cl» для «Client»). Не используйте универсальные имена, такие как «я», «это» или «я», идентификаторы, типичные для объектно-ориентированных языков, в которых больше внимания уделяется методам, а не функциям. Имя не обязательно должно быть таким же описательным, как и у аргумента метода, поскольку его роль очевидна и не имеет никакой документальной цели. Он может быть очень коротким, поскольку он будет отображаться почти в каждой строке каждого метода типа; фамильярность допускает краткость. Также будьте последовательны: если вы вызываете получатель «c» в одном методе, не называйте его «cl» в другом.

 icza09 авг. 2016 г., 10:59
@ Дейл. Делай, что хочешь. Никто не заставит вас что-либо делать. И пока вы пишете «один», это не будет беспокоить кого-либо еще. Но если вы хотите работать с другими, или другие должны работать с вашим кодом, вам нужно говорить на «общем» языке. относительноthis а такжеself в качестве приемника метода:В Go вводящее в заблуждение название переменной-получателя вводит в заблуждение?
 Dale09 авг. 2016 г., 11:04
Спасибо. Я не хочу спорить. Я планирую на открытых источниках эту кучу. Возможно, обратная связь заставит меня переосмыслить свое решение. Я все еще не убежден в решениях дизайнеров здесь. При этом почти все остальное, что я видел в Go, было очень впечатляющим.
 Dale09 авг. 2016 г., 10:52
Интерфейсы с одним методом «проще». «Есть <что-то> ()» сбивало меня с толку. В итоге я просто использовал "checker ()". Да, извините, я не собираюсь использовать одно- или двухбуквенные идентификаторы. Мне все равно, что здесь идиоматично. Я знаю полдюжины языков, которые используют это или себя, зачем мне нарушать соглашение здесь просто потому, что какой-то документ в спецификации языка говорит, что я должен? Это или я это именно то, что я имею в виду и чего я хочу. В конце концов, мне нужно прочитать мой код, и если я копаюсь в своих спегетти, чтобы найти какой-нибудь однобуквенный идентификатор, какой смысл?

Ваш ответ на вопрос