Swift-style-guide: Именование протоколов

Я думаю, что было бы сложно перевести стиль имен C # на Swift. «Я» для интерфейса работает в .NET из-за различий в пространстве имен.

Что касается герундий («способный» и «инг»), я считаю, что они работают так же, как и в английском языке:
«Герундий - это существительное, образованное от глагола добавлением« -ing ».

Например: мне нужно хешировать (глагол) этот класс, он хешируется (герундий)? Я хочу сравнить (глагол), сопоставим ли этот класс (герундий)?

Если вы посмотрите на C #, они также не используют герундий для всех интерфейсов. Возьмем Point (класс) и IPoint (интерфейс, реализующий X и Y). Делать что-то значимое было бы немного неверным.

Мне подходят такие протоколы, как UITableViewDelegate и UITableViewDataSource. У меня лично нет проблем с суффиксом ... Protocol, но я бы не хотел этого как правило. Иногда «способный» работает лучше, иногда другие суффиксы имеют смысл, например ... Delegate или ... DataSource.

Я считаю, что если бы они были созданы сегодня, они бы назывались UITableViewDelegateType и UITableViewDataSourceType. Грег Хео называет это «это»: http://www.skilled.io/gregheo/what-the-55-swift-standard-library-protocols-taught-me

Многие из моих собственных протоколов инкапсулируют только одну функцию или свойство. У Swift нет проблем с тем, чтобы назвать протокол таким же, и я думаю, что это очень чистый подход.

protocol bool {
   var bool: Bool {get}
}

struct Struct: bool {
   let bool = true
}

При необходимости я буду использовать обычное соглашение об именах делегатов и источников данных, но для протоколов, которые просто используются для создания объектов, я только что поместил Protocol в имя. Не уверен, что это лучшая практика или нет, когда я исследовал ее, я не смог найти никакой информации.

protocol AlertModalProtocol {
func titleText() -> String
func messageText() -> String
}

struct NewUserAlertModal: AlertModalProtocol {

    func titleText() -> String {
        return "Welcome new user"
    }

    func messageText() -> String {
        return "Thanks for joining the app."
    }
}

Суффикс «Тип», кажется, повторяет путь динозавра, хотя мне показалось, что я видел, как пролетело предложение использовать «Протокол», как @mitchellporter .

Из Руководства по дизайну Swift API :

Протоколы, описывающие что-то, следует читать как существительные (например, Сборник). Протоколы, описывающие возможности, должны быть названы с использованием суффиксов «able »,« ible »или« ing »(например, Equatable, ProgressReporting).

Это интересно. По моему опыту, ThingType был необходим, когда Thing традиционно был неабстрактным классом. (т.е. Thing - это конкретный тип, который реализует ThingType, а другие типы, которые более конкретны, также реализуют ThingType.) NSObjectProtocol является примером такого рода вещей.

Я добавлю текст по строкам черновика API Design Guidelines.

БЫСТРЫЙ
Наблюдая за чужим кодом, я столкнулся с проблемой, что протоколы, которые описывают, что это такое, когда они являются существительными, втихомолку неудобны, потому что я часто путаю это с методами класса. Чтобы решить эту проблему, я думаю, лучший способ использовать следующее правило:

When the protocol name is a noun - write ..Protocol (yes, even in swift);
например PhotoModuleProtocol
When the protocol is an adverb or an adjective - write ..able, ..ing and so on;
например, Testable

На мой взгляд, лучше прямо сейчас, что такое отсчет времени на распознавание чьего-либо кода, чем хипстерские вещи Swift.

Я опубликовал свой последний комментарий еще в 2015 году ... с тех пор я перешел в основном на то, чем ранее поделился

Протоколы, описывающие что-то, следует читать как существительные (например, Сборник). Протоколы, описывающие возможности, должны быть названы с использованием суффиксов «able »,« ible »или« ing »(например, Equatable, ProgressReporting).

Так, например, обычно существует тип базовой модели, который будет выглядеть следующим образом:

protocol BaseType {
    var objectId: String { get set }
    var createdAt: NSDate? { get set }
    var updatedAt: NSDate? { get set }
    func toJSON() -> [String: AnyObject]
    static func from(json: [String: AnyObject]) -> AnyObject
}

Поскольку все модели в приложении будут нуждаться в этой функции, все они будут соответствовать BaseType . На самом деле я назвал этот базовый тип после имени приложения, поэтому, если имя вашего приложения было Instagram это было бы InstagramType . Теперь, когда я думаю об этом, включение Type в имя кажется бессмысленным ... нет причин, по которым вы не могли бы назвать это BaseModel , InstagramModel или даже всего Model .

Что касается протоколов, которые описывают возможности, я также использовал суффиксы типа «could», «ible» и «ing».

Я перестал использовать слово protocol в своих именах, потому что оно казалось излишним, и я также чувствовал, что использую его, чтобы всем было очень легко понять: «Эй, это протокол, а не класс», который чувствовал неверно, поскольку протоколы должны рассматриваться как равные классам, если не выше их, в быстром темпе.

Поэтому вместо того, чтобы выделять их, включив протокол в название, я просто опускаю его. Это как раз то, что мне кажется правильным, я не утверждаю, что это правильно или неправильно. Даже годы спустя я всегда открываю для себя что-то новое в Swift, и я бросил попытки во всем разобраться. На самом деле просто пытаюсь поэкспериментировать и посмотреть, что на данный момент придумает сообщество :)

Тем не менее, именование протоколов по существительному приводит к добавлению некоторых слов (это может быть "..Model", "..Type" и так далее), чтобы определить, что это протокол, а не класс. Изменения только в том, какое это слово использовать =)