既存のオブジェクトに拡張子を追加する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拡張子が与えられた場合、迅速なソースファイルは何と呼ばれるべきですか？

私が見たほとんどの例は、Objective-Cアプローチを模倣しています。上記の拡張の例は次のようになります。

String+UTF8Data.swift

利点は、命名規則により、それが拡張であること、およびどのクラスが拡張されているかを簡単に理解できることです。

を使用したExtensions.swift場合の問題StringExtensions.swiftは、ファイルの内容を見ずに名前でファイルの目的を推測できないことです。

xxxable.swiftJavaで使用されているアプローチを使用すると、メソッドのみを定義するプロトコルまたは拡張機能で問題なく機能します。しかし、繰り返しになりますが、上記の例では属性を定義しているため、UTF8Dataable.swift文法的にはあまり意味がありません。

Swift規約はありません。単純にする：

StringExtensions.swift

拡張するクラスごとに1つのファイルを作成します。すべての拡張子に単一のファイルを使用すると、すぐにジャングルになります。

StringExtensions.swift追加するファイルが多すぎてファイルをString+utf8Data.swiftandのようなものに分割するまで、私は好みますString+Encrypt.swift。

もう1つ、類似のファイルを1つに結合すると、ビルドがより高速になります。Optimizing-Swift-Build-Timesを参照してください

チームが合意した一般的およびその他の拡張機能のセットがある場合は、Extensions.swiftがKeep-It-Simpleの第1レベルのソリューションとして機能するようにまとめます。ただし、複雑さが増すか、拡張機能が複雑になるにつれて、複雑さをカプセル化するための階層が必要になります。そのような状況では、次の例を使用して練習することをお勧めします。

と呼ばれるバックエンドと会話するクラスがありましたServer。2つの異なるターゲットアプリをカバーするように大きくなり始めました。一部の人々は大きなファイルが好きですが、論理的には拡張子で分割されます。私の好みは、各ファイルを比較的短く保つことなので、次の解決策を選択しました。 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を実装します。実際の作業は2つのファイルに分割されます。

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

これらはそれぞれのプロトコルを実装します。

これは、他のファイル（この例ではAlamofireの場合）にインポート宣言を含める必要があることを意味しますが、私の見解ではインターフェースを分離するという点でクリーンなソリューションです。

このアプローチは、外部で指定されたクラスだけでなく、独自のクラスでも同様に機能すると思います。

なぜこれは議論でさえあるのですか？すべてのサブクラスを_Subclasses.swiftというファイルに配置する必要があります。私はそうは思いません。Swiftにはモジュールベースの名前間隔があります。よく知られているSwiftクラスを拡張するには、その目的に固有のファイルが必要です。UIViewExtensions.swiftであるファイルを作成する大規模なチームがあり、それが目的を示さず、開発者を混乱させ、ビルドしないプロジェクトで簡単に複製される可能性があります。Objective-Cの命名規則は適切に機能し、Swiftに実際の名前間隔ができるまでは、これが最善の方法です。

あちこちにコメントを追加するのではなく、1つの回答ですべてのコメントをここに表示します。

個人的には、拡張性のあるオブジェクトのAPI表面を乱雑にすることなく、優れた使いやすさと明確さの両方を提供するハイブリッドアプローチを採用しています。

たとえば、andのように、任意の文字列で使用できるようになっているものであれば何でも使用できます。StringExtensions.swifttrimRight()removeBlankLines()

私のような拡張機能を持っていた場合しかし、formatAsAccountNumber()それは考えていないそのファイルに行く「口座番号」は、自然に任意の/すべての文字列のみのアカウントのコンテキストで理にかなっているに適用されるものではありませんので。その場合は、私が呼ばれるファイルを作成しますStrings+AccountFormatting.swiftでも多分かStrings+CustomFormatting.swiftでformatAsAccountNumber()実際にそれをフォーマットするには、いくつかの種類/かの方法がある場合、関数。

実際、最後の例では、私は最初にそのような拡張機能を使用しないよう積極的にチームを説得しました。AccountNumberFormatter.format(String)代わりに、StringAPIサーフェスにまったく触れないようにする必要がないため、代わりにそのようなものを奨励します。例外は、その拡張子を、それが使用されているのと同じファイルで定義した場合ですが、それでも、独自のファイル名はありません。

私は+それが拡張機能を含んでいるという事実に下線を引くことを好む：

String+Extensions.swift

ファイルが大きくなりすぎた場合は、目的ごとに分割できます。

String+UTF8Data.swift

String+Encrypt.swift