기존 객체에 확장자를 추가하는 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

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

내가 좋아 StringExtensions.swift내가 좋아하는 무언가로 파일을 분할 너무 많은 일을 추가 할 때까지 String+utf8Data.swift하고 String+Encrypt.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의 경우)에 가져 오기 선언이 필요하지만 내 관점에서 인터페이스를 분리하는 관점에서 깨끗한 솔루션을 가져야한다는 것을 의미합니다.

이 접근법은 외부에서 지정한 클래스뿐만 아니라 자신의 클래스와 똑같이 잘 작동한다고 생각합니다.

이것이 왜 논쟁인가? 모든 하위 클래스를 _Subclasses.swift라는 파일에 넣어야합니다. 나는 그렇게 생각하지 않는다. 스위프트는 모듈 기반 이름 간격을 가지고 있습니다. 잘 알려진 Swift 클래스를 확장하려면 용도에 맞는 파일이 필요합니다. UIViewExtensions.swift 파일을 작성하여 목적을 나타내지 않으며 개발자를 혼란스럽게 만들고 빌드하지 않는 프로젝트에서 쉽게 복제 할 수있는 큰 팀을 만들 수 있습니다. Objective-C 이름 지정 규칙은 제대로 작동하며 Swift가 실제 이름 간격을 가질 때까지 가장 좋은 방법입니다.

장소에 내 의견을 추가하는 것이 아니라 하나의 답변으로 여기에 의견을 제시하고 있습니다.

개인적으로, 나는 확장하고있는 객체의 API 표면 영역을 어지럽히 지 않으면 서 좋은 유용성과 명확성을 제공하는 하이브리드 접근 방식을 취합니다.

예를 들어 있다는 것을 차종은 감각 에 사용할 수 있는 갈 것이다 문자열 StringExtensions.swift과 같은 trimRight()및 removeBlankLines().

내가 같은 확장 기능이 있다면 그러나, formatAsAccountNumber()그것은 것입니다 하지 '계좌 번호'가 자연스럽게 하나에 적용 무언가가 아니기 때문에 해당 파일의 이동을 / 모든 문자열과는 계정의 맥락에서 의미가 있습니다. 이 경우, 나는라는 파일을 만들 것 Strings+AccountFormatting.swift조차 어쩌면 또는 Strings+CustomFormatting.swift로모그래퍼 formatAsAccountNumber()실제로 포맷하기 위해 여러 종류 / 방법이있는 경우 기능.

실제로, 마지막 예에서, 나는 팀이 처음에 이와 같은 확장을 사용하지 않도록 적극적으로 설득하고 대신 API 표면 영역에 전혀 AccountNumberFormatter.format(String)닿지 않아야 하는 것과 같은 것을 권장 String합니다. 확장자가 사용 된 파일과 동일한 파일에 해당 확장자를 정의한 경우에는 자체 파일 이름이없는 경우는 예외입니다.

+확장명이 포함되어 있다는 사실에 밑줄을 긋는 것을 선호 합니다.

String+Extensions.swift

파일이 너무 커지면 각 목적에 맞게 분할 할 수 있습니다.

String+UTF8Data.swift

String+Encrypt.swift