Как лучше всего именовать файлы Swift, которые добавляют расширения к существующим объектам?

Можно добавить расширения к существующим типам объектов Swift, используя расширения, как описано в спецификации языка .

В результате возможно создание расширений, таких как:

extension String {
    var utf8data:NSData {
        return self.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)!
    }
}

Тем не менее, какова наилучшая практика именования исходных файлов Swift, содержащих такие расширения?

В прошлом, соглашение было использовать extendedtype+categoryname.mдля типа Objective-C , как описано в руководстве по Objective-C . Но в примере Swift нет названия категории, и называть его String.swiftнеуместно.

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

Большинство примеров, которые я видел, имитируют подход Objective-C. Пример расширения выше будет:

String+UTF8Data.swift

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

Проблема с использованием Extensions.swiftили даже StringExtensions.swiftв том, что невозможно определить назначение файла по его имени, не глядя на его содержимое.

Использование xxxable.swiftподхода, используемого Java, работает нормально для протоколов или расширений, которые определяют только методы. Но опять же, в приведенном выше примере атрибут определяется так, что UTF8Dataable.swiftон не имеет большого грамматического смысла.

Свифта нет. Будь проще:

StringExtensions.swift

Я создаю один файл для каждого расширяемого класса. Если вы используете один файл для всех расширений, он быстро превратится в джунгли.

Я предпочитаю, StringExtensions.swiftпока я не добавил слишком много вещей, чтобы разбить файл на что-то вроде String+utf8Data.swiftи String+Encrypt.swift.

Еще одна вещь, объединение одинаковых файлов в один сделает ваше здание быстрее. Обратитесь к разделу «Оптимизация-Сдвиг-Время сборки»

Если у вас есть согласованный командой набор общих и разных улучшений, объедините их вместе в виде Extensions.swift и используйте в качестве решения первого уровня Keep-It-Simple. Однако по мере того, как ваша сложность возрастает, или расширения становятся более сложными, для инкапсуляции сложности необходима иерархия. В таких условиях я рекомендую следующую практику с примером.

У меня был класс, который говорит с моим бэкэндом, называется Server. Он начал расти, чтобы охватить два разных целевых приложения. Некоторым людям нравится большой файл, но он логически разделен с расширениями. Я предпочитаю, чтобы каждый файл был относительно коротким, поэтому я выбрал следующее решение. Serverизначально соответствовал CloudAdapterProtocolи реализовывал все свои методы. Что я сделал, так это превратил протокол в иерархию, сделав ссылку на подчиненные протоколы:

protocol CloudAdapterProtocol: ReggyCloudProtocol, ProReggyCloudProtocol {
    var server: CloudServer {
        get set
    }
    func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void)
}

У Server.swiftменя есть

import Foundation
import UIKit
import Alamofire
import AlamofireImage

class Server: CloudAdapterProtocol {
.
.
func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void) {
.
.
}

Server.swiftзатем просто реализует API главного сервера для настройки сервера и получения версии API. Настоящая работа разбита на два файла:

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

Они реализуют соответствующие протоколы.

Это означает, что вам нужно иметь объявления импорта в других файлах (для Alamofire в этом примере), но на мой взгляд, это чистое решение с точки зрения разделения интерфейсов.

Я думаю, что этот подход одинаково хорошо работает как с внешними классами, так и с вашими.

Почему это даже спор? Должен ли я поместить все мои подклассы в файл с именем _Subclasses.swift. Думаю, нет. Swift имеет основанный на модуле интервал имен. Для расширения хорошо известного класса Swift необходим файл, который соответствует его назначению. У меня могла бы быть большая команда, которая создает файл UIViewExtensions.swift, который не выражает никакой цели и может сбить с толку разработчиков и может быть легко продублирован в проекте, который не будет создаваться. Соглашение об именах Objective-C работает нормально, и пока Swift не получит реальный интервал имен, это лучший путь.

Вместо того, чтобы добавлять свои комментарии повсюду, я выкладываю их здесь в одном ответе.

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

Например, все, что имеет смысл быть доступным для какой-либо строки, будет содержать, StringExtensions.swiftнапример, trimRight()и removeBlankLines().

Тем не менее, если бы у меня была функция расширения, такая как formatAsAccountNumber()она не была бы в этом файле, потому что «Номер счета» не является чем-то, что естественно применимо к любым / всем строкам и имеет смысл только в контексте учетных записей. В этом случае я бы создал файл с именем Strings+AccountFormatting.swiftили, может быть, даже Strings+CustomFormatting.swiftс formatAsAccountNumber()функцией, если есть несколько типов / способов для его форматирования.

На самом деле, в этом последнем примере я активно отговаривал свою команду от использования подобных расширений, и вместо этого поощрял бы что-то вроде AccountNumberFormatter.format(String)этого, поскольку это вообще не затрагивает область Stringповерхности API, как это не должно быть. Исключением может быть то, что вы определили это расширение в том же файле, где оно используется, но в любом случае у него не будет собственного имени.

Я предпочитаю +подчеркивать тот факт, что он содержит расширения:

String+Extensions.swift

И если файл становится слишком большим, вы можете разделить его для каждой цели:

String+UTF8Data.swift

String+Encrypt.swift