Qual è la migliore pratica per nominare i file Swift che aggiungono estensioni agli oggetti esistenti?

È possibile aggiungere estensioni ai tipi di oggetti Swift esistenti usando le estensioni, come descritto nelle specifiche del linguaggio .

Di conseguenza, è possibile creare estensioni come:

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

Tuttavia, qual è la migliore pratica di denominazione per i file sorgente Swift contenenti tali estensioni?

In passato, la convenzione doveva essere utilizzata extendedtype+categoryname.mper il tipo Objective-C come discusso nella guida Objective-C . Ma l'esempio Swift non ha un nome di categoria e chiamarlo String.swiftnon sembra appropriato.

Quindi la domanda è: data l' Stringestensione sopra , come dovrebbe essere chiamato il file sorgente rapido?

La maggior parte degli esempi che ho visto imitano l'approccio Objective-C. L'estensione di esempio sopra sarebbe:

String+UTF8Data.swift

I vantaggi sono che la convenzione di denominazione semplifica la comprensione del fatto che si tratta di un'estensione e di quale classe viene estesa.

Il problema con l'utilizzo Extensions.swifto addirittura StringExtensions.swiftè che non è possibile inferire lo scopo del file con il suo nome senza guardarne il contenuto.

L'uso xxxable.swiftdell'approccio usato da Java funziona bene per protocolli o estensioni che definiscono solo metodi. Ma ancora, l'esempio sopra definisce un attributo in modo che UTF8Dataable.swiftnon abbia molto senso grammaticale.

Non esiste una convenzione Swift. Mantienilo semplice:

StringExtensions.swift

Creo un file per ogni classe che sto estendendo. Se usi un singolo file per tutte le estensioni, diventerà rapidamente una giungla.

Preferisco StringExtensions.swiftfino a quando non ho aggiunto troppe cose per dividere il file in qualcosa di simile String+utf8Data.swifte String+Encrypt.swift.

Un'altra cosa, combinare file simili in uno renderà il tuo edificio più veloce. Fare riferimento a Optimizing-Swift-Build-Times

Se disponi di una serie concordata di miglioramenti comuni e vari, raggruppandoli come Extensions.swift funziona come soluzione di primo livello Keep-It-Simple. Tuttavia, man mano che la complessità aumenta o le estensioni diventano più coinvolte, è necessaria una gerarchia per incapsulare la complessità. In tali circostanze raccomando la seguente pratica con un esempio.

Ho tenuto una lezione che parla al mio back-end, chiamata Server. Ha iniziato a crescere per coprire due diverse app target. Ad alcune persone piace un file di grandi dimensioni, ma logicamente diviso con estensioni. La mia preferenza è quella di mantenere ogni file relativamente breve, quindi ho scelto la seguente soluzione. Serveroriginariamente conforme CloudAdapterProtocole implementato tutti i suoi metodi. Quello che ho fatto è stato trasformare il protocollo in una gerarchia, facendo in modo che si riferisse a protocolli subordinati:

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

In Server.swiftho

import Foundation
import UIKit
import Alamofire
import AlamofireImage

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

Server.swiftquindi implementa semplicemente l'API del server principale per impostare il server e ottenere la versione dell'API. Il vero lavoro è diviso in due file:

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

Questi implementano i rispettivi protocolli.

Significa che devi avere dichiarazioni di importazione negli altri file (per Alamofire in questo esempio) ma è una soluzione pulita in termini di separazione delle interfacce a mio avviso.

Penso che questo approccio funzioni ugualmente bene con le classi specificate esternamente e le tue.

Perché questo è persino un dibattito? Devo mettere tutte le mie sottoclassi in un file chiamato _Subclasses.swift. Penso di no. Swift ha una spaziatura dei nomi basata sul modulo. Per estendere una ben nota classe Swift è necessario un file specifico per il suo scopo. Potrei avere una grande squadra che crea un file che è UIViewExtensions.swift che non esprime alcuno scopo e confonde gli sviluppatori e potrebbe essere facilmente duplicato nel progetto che non sarebbe stato creato. La convenzione di denominazione Objective-C funziona bene e fino a quando Swift non ha una spaziatura dei nomi reale, è il modo migliore di procedere.

Piuttosto che aggiungere i miei commenti in tutto il luogo, li sto emergendo tutti qui in una risposta.

Personalmente, adotto un approccio ibrido che offre sia una buona usabilità che chiarezza, senza ingombrare la superficie dell'API per l'oggetto che sto estendendo.

Ad esempio, tutto ciò che ha senso essere disponibile per qualsiasi stringa andrebbe in StringExtensions.swiftcome trimRight()e removeBlankLines().

Tuttavia, se avessi una funzione di estensione come formatAsAccountNumber()questa non andrebbe in quel file perché "Numero account" non è qualcosa che si applicherebbe naturalmente a qualsiasi / tutte le stringhe e ha senso solo nel contesto degli account. In tal caso, creerei un file chiamato Strings+AccountFormatting.swifto forse anche Strings+CustomFormatting.swiftcon una formatAsAccountNumber()funzione se ci sono diversi tipi / modi per formattarlo effettivamente.

In realtà, in quell'ultimo esempio, ho dissuaso attivamente il mio team dall'utilizzare estensioni come quella in primo luogo, e incoraggerei invece qualcosa del genere AccountNumberFormatter.format(String)invece che non tocca affatto la Stringsuperficie dell'API, come non dovrebbe. L'eccezione sarebbe se tu avessi definito quell'estensione nello stesso file in cui è usata, ma non avrebbe comunque il suo nome file.

Preferisco avere un +per sottolineare il fatto che contiene estensioni:

String+Extensions.swift

E se il file diventa troppo grande, puoi quindi dividerlo per ogni scopo:

String+UTF8Data.swift

String+Encrypt.swift