Cách thực hành tốt nhất để đặt tên tệp Swift có thêm tiện ích mở rộng cho các đối tượng hiện có là gì?

Có thể thêm tiện ích mở rộng cho các loại đối tượng Swift hiện có bằng cách sử dụng tiện ích mở rộng, như được mô tả trong đặc tả ngôn ngữ .

Do đó, có thể tạo các tiện ích mở rộng như:

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

Tuy nhiên, cách thực hành đặt tên tốt nhất cho các tệp nguồn Swift có chứa các phần mở rộng như vậy là gì?

Trước đây, quy ước là sử dụng extendedtype+categoryname.mcho loại Objective-C như được thảo luận trong hướng dẫn Objective-C . Nhưng ví dụ Swift không có tên danh mục và gọi nó String.swiftcó vẻ không phù hợp.

Vì vậy, câu hỏi là: với Stringphần mở rộng ở trên , tập tin nguồn swift nên được gọi là gì?

Hầu hết các ví dụ tôi đã thấy bắt chước cách tiếp cận Objective-C. Phần mở rộng ví dụ ở trên sẽ là:

String+UTF8Data.swift

Ưu điểm là quy ước đặt tên giúp dễ hiểu rằng đó là một phần mở rộng và Class nào đang được mở rộng.

Vấn đề với việc sử dụng Extensions.swifthoặc thậm chí StringExtensions.swiftlà không thể suy ra mục đích của tệp theo tên của nó mà không nhìn vào nội dung của nó.

Sử dụng xxxable.swiftcách tiếp cận như được sử dụng bởi Java hoạt động ổn đối với các giao thức hoặc phần mở rộng chỉ xác định các phương thức. Nhưng một lần nữa, ví dụ trên định nghĩa một thuộc tính sao cho UTF8Dataable.swiftkhông có nhiều ý nghĩa ngữ pháp.

Không có quy ước Swift. Giữ cho nó đơn giản:

StringExtensions.swift

Tôi tạo một tệp cho mỗi lớp tôi đang mở rộng. Nếu bạn sử dụng một tệp duy nhất cho tất cả các tiện ích mở rộng, nó sẽ nhanh chóng trở thành một khu rừng.

Tôi thích StringExtensions.swiftcho đến khi tôi thêm quá nhiều thứ để chia tập tin thành một cái gì đó như String+utf8Data.swiftvà String+Encrypt.swift.

Một điều nữa, để kết hợp các tệp tương tự thành một sẽ làm cho tòa nhà của bạn nhanh hơn. Tham khảo Tối ưu hóa-Swift-Build-Times

Nếu bạn có một tập hợp các cải tiến phổ biến và linh tinh theo nhóm đã đồng ý, hãy kết hợp chúng lại với nhau như một Phần mở rộng.swift hoạt động như một giải pháp cấp đầu tiên Keep-It-Simple. Tuy nhiên, khi độ phức tạp của bạn tăng lên hoặc các phần mở rộng trở nên liên quan hơn, thì cần có một hệ thống phân cấp để gói gọn sự phức tạp. Trong trường hợp như vậy tôi khuyên bạn nên thực hành sau đây với một ví dụ.

Tôi đã có một lớp học nói chuyện với back-end của tôi, được gọi Server. Nó bắt đầu phát triển lớn hơn để bao gồm hai ứng dụng mục tiêu khác nhau. Một số người thích một tệp lớn nhưng chỉ cần phân tách hợp lý với các tiện ích mở rộng. Sở thích của tôi là giữ mỗi tệp tương đối ngắn nên tôi chọn giải pháp sau. Serverban đầu tuân thủ CloudAdapterProtocolvà thực hiện tất cả các phương pháp của nó. Những gì tôi đã làm là biến giao thức thành một hệ thống phân cấp, bằng cách làm cho nó tham chiếu đến các giao thức phụ:

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

Trong Server.swifttôi có

import Foundation
import UIKit
import Alamofire
import AlamofireImage

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

Server.swiftsau đó chỉ cần thực hiện API máy chủ lõi để thiết lập máy chủ và nhận phiên bản API. Công việc thực sự được chia thành hai tệp:

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

Chúng thực hiện các giao thức tương ứng.

Điều đó có nghĩa là bạn cần phải có các khai báo nhập khẩu trong các tệp khác (đối với Alamofire trong ví dụ này) nhưng đó là một giải pháp rõ ràng về mặt cách ly các giao diện theo quan điểm của tôi.

Tôi nghĩ cách tiếp cận này hoạt động tốt như nhau với các lớp được chỉ định bên ngoài cũng như của riêng bạn.

Tại sao điều này thậm chí là một cuộc tranh luận? Tôi có nên đặt tất cả các lớp con của mình vào một tệp có tên _Subgroupes.swift. Tôi nghĩ là không. Swift có khoảng cách tên dựa trên mô-đun. Để mở rộng một lớp Swift nổi tiếng cần một tệp dành riêng cho mục đích của nó. Tôi có thể có một nhóm lớn tạo ra một tệp là UIViewExtensions.swift không có mục đích và sẽ gây nhầm lẫn cho các nhà phát triển và có thể dễ dàng bị trùng lặp trong dự án không xây dựng. Quy ước đặt tên Objective-C hoạt động tốt và cho đến khi Swift có khoảng cách tên thật, đó là cách tốt nhất để đi.

Thay vì thêm ý kiến ​​của tôi ở khắp mọi nơi, tôi sẽ lướt tất cả chúng ở đây trong một câu trả lời.

Cá nhân, tôi thực hiện một cách tiếp cận lai mang lại cả khả năng sử dụng tốt và rõ ràng, đồng thời không làm lộn xộn diện tích bề mặt API cho đối tượng mà tôi đang mở rộng.

Ví dụ, bất cứ điều gì có ý nghĩa có sẵn cho bất kỳ chuỗi nào sẽ đi vào StringExtensions.swiftnhư trimRight()và removeBlankLines().

Tuy nhiên, nếu tôi có chức năng mở rộng như formatAsAccountNumber()nó sẽ không xuất hiện trong tệp đó vì 'Số tài khoản' không phải là thứ sẽ tự nhiên áp dụng cho bất kỳ / tất cả các chuỗi và chỉ có ý nghĩa trong ngữ cảnh của tài khoản. Trong trường hợp đó, tôi sẽ tạo một tệp có tên Strings+AccountFormatting.swifthoặc thậm chí Strings+CustomFormatting.swiftvới một formatAsAccountNumber()hàm nếu có một số loại / cách để thực sự định dạng nó.

Trên thực tế, trong ví dụ cuối cùng đó, tôi đã chủ động không cho nhóm của mình sử dụng các tiện ích mở rộng như thế ở nơi đầu tiên, và thay vào đó sẽ khuyến khích một cái gì đó giống như điều đó AccountNumberFormatter.format(String)thay vào đó không chạm vào Stringdiện tích bề mặt API, vì nó không nên. Trường hợp ngoại lệ sẽ là nếu bạn xác định tiện ích mở rộng đó trong cùng một tệp được sử dụng, nhưng sau đó nó sẽ không có tên tệp riêng.

Tôi thích có một +gạch chân thực tế nó chứa các phần mở rộng:

String+Extensions.swift

Và nếu tệp quá lớn, bạn có thể chia nó cho từng mục đích:

String+UTF8Data.swift

String+Encrypt.swift