기존 객체에 확장자를 추가하는 Swift 파일의 이름을 지정하는 가장 좋은 방법은 무엇입니까?

기존 객체에 확장자를 추가하는 Swift 파일의 이름을 지정하는 가장 좋은 방법은 무엇입니까?

---

언어 사양에 설명 된대로 확장을 사용하여 기존 Swift 객체 유형에 확장을 추가 할 수 있습니다 .

결과적으로 다음과 같은 확장을 만들 수 있습니다.

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

그러나 그러한 확장자를 포함하는 Swift 소스 파일에 가장 적합한 명명 방법은 무엇입니까?

과거에이 규칙은 Objective-C 안내서extendedtype+categoryname.m 에서 논의 된 것처럼 Objective-C 유형 에 사용 되었습니다 . 그러나 Swift 예제에는 범주 이름 이 없으므로 호출하는 것이 적절하지 않습니다.String.swift

질문은 위의 String확장명을 사용하면 신속한 소스 파일을 어떻게 호출해야합니까?

---

내가 본 대부분의 예제는 Objective-C 접근 방식을 모방 한 것입니다. 위의 예제 확장은 다음과 같습니다.

String+UTF8Data.swift

장점은 이름 지정 규칙이 그것이 확장이고 어떤 클래스가 확장되고 있는지 쉽게 이해할 수 있다는 것입니다.

Extensions.swift또는 사용의 문제점 StringExtensions.swift은 파일 내용을 보지 않고 파일 이름을 파일의 목적으로 유추 할 수 없다는 것입니다.

xxxable.swiftJava가 사용하는 방식을 사용 하면 메소드 만 정의하는 프로토콜 또는 확장에 적합합니다. 그러나 위의 예는 UTF8Dataable.swift문법적으로 의미가없는 속성을 정의합니다 .

---

스위프트 컨벤션은 없습니다. 간단하게 유지하십시오.

StringExtensions.swift

내가 확장하는 각 클래스마다 하나의 파일을 만듭니다. 모든 확장명에 단일 파일을 사용하면 빠르게 정글이됩니다.

---

선호하는 것은 파일의 시작 부분에 "Extension_"을 두는 것입니다. (모든 관련 확장명을 같은 파일에 넣었습니다.)

이렇게하면 모든 확장 파일이 내 앱의 디렉토리와 Xcode의 탐색기에 알파벳순으로 함께 있습니다. 물론 네비게이터에서도 그룹화 할 수 있습니다.

따라서 문자열 관련 확장은 Extension_String.swift

---

팀이 합의한 공통 및 기타 개선 사항이있는 경우 Extensions.swift를 함께 묶으면 간단한 첫 번째 수준의 솔루션으로 작동합니다. 그러나 복잡성이 커지거나 확장이 더 복잡해지면 복잡성을 캡슐화하기위한 계층 구조가 필요합니다. 그러한 상황에서는 다음과 같은 사례를 예로들 것을 권장합니다.

나는 백엔드와 대화하는 수업을했습니다 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의 경우)에 가져 오기 선언이 필요하지만 내 관점에서 인터페이스를 분리하는 관점에서 깨끗한 솔루션을 가져야한다는 것을 의미합니다.

I think this approach works equally well with externally specified classes as well as your own.

---

I prefer StringExtensions.swift until I added too much things to split the file to something like String+utf8Data.swift and String+Encrypt.swift.

One more thing, to combine similar files into one will make your building more faster. Refer to Optimizing-Swift-Build-Times

참고URL : https://stackoverflow.com/questions/26319660/whats-the-best-practice-for-naming-swift-files-that-add-extensions-to-existing