ios - programacion - swift(lenguaje de programación)

¿Cuál es la mejor práctica para nombrar archivos Swift que agregan extensiones a objetos existentes?

Question

Es posible agregar extensiones a los tipos de objeto Swift existentes utilizando extensiones, como se describe en la especificación del lenguaje .

Como resultado, es posible crear extensiones tales como:

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

Sin embargo, ¿cuál es la mejor práctica de nomenclatura para los archivos fuente de Swift que contienen dichas extensiones?

En el pasado, la convención era usar extendedtype+categoryname.m para el tipo Objective-C como se discutió en la guía Objective-C . Pero el ejemplo de Swift no tiene un nombre de categoría, y llamarlo String.swift no parece apropiado.

Entonces la pregunta es: dada la extensión de String anterior, ¿cómo se debería llamar el archivo de origen rápido?

Answer 1

La mayoría de los ejemplos que he visto imitan el enfoque de Objective-C. La extensión de ejemplo anterior sería:

String+UTF8Data.swift

Las ventajas son que la convención de nomenclatura hace que sea fácil entender que es una extensión y qué clase se está ampliando.

El problema con el uso de Extensions.swift o incluso StringExtensions.swift es que no es posible inferir el propósito del archivo por su nombre sin mirar su contenido.

Usar el enfoque xxxable.swift como lo usa Java funciona bien para protocolos o extensiones que solo definen métodos. Pero, de nuevo, el ejemplo anterior define un atributo para que UTF8Dataable.swift no tenga mucho sentido gramatical.

Answer 2

Mi preferencia es poner "Extension_" al principio del archivo. (Puse todas las extensiones relacionadas en el mismo archivo).

De esta forma, todos los archivos de extensión están juntos, alfabéticamente, en el directorio de mi aplicación y en el navegador de Xcode. Por supuesto, en el navegador, puedo agruparlos también.

Entonces, una extensión relacionada con String entraría en Extension_String.swift

Answer 3

No hay convención Swift. Mantenlo simple:

StringExtensions.swift

Creo un archivo para cada clase que extiendo. Si usa un único archivo para todas las extensiones, se convertirá rápidamente en una jungla.

Answer 4

Prefiero StringExtensions.swift hasta que agregué demasiadas cosas para dividir el archivo en algo como String+utf8Data.swift y String+Encrypt.swift .

Una cosa más, combinar archivos similares en uno hará que su edificio sea más rápido. Consulte Optimizing-Swift-Build-Times

Answer 5

Si tiene un conjunto acordado por el equipo de mejoras comunes y misceláneas, aglutinándolas juntas como Extensions.swift funciona como la solución de primer nivel Keep-It-Simple. Sin embargo, a medida que crece su complejidad o las extensiones se vuelven más complicadas, se necesita una jerarquía para encapsular la complejidad. En tales circunstancias, recomiendo la siguiente práctica con un ejemplo.

Tuve una clase que habla con mi back-end, llamado Server . Comenzó a crecer para cubrir dos aplicaciones de destino diferentes. Algunas personas prefieren un archivo grande pero simplemente se dividen lógicamente con extensiones. Mi preferencia es mantener cada archivo relativamente corto, así que elegí la siguiente solución. Server originalmente se conformó a CloudAdapterProtocol e implementó todos sus métodos. Lo que hice fue convertir el protocolo en una jerarquía, haciendo que se refiera a protocolos subordinados:

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

En Server.swift tengo

import Foundation
import UIKit
import Alamofire
import AlamofireImage

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

Server.swift luego implementa la API del servidor central para configurar el servidor y obtener la versión de la API. El trabajo real se divide en dos archivos:

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

Estos implementan los protocolos respectivos.

Significa que necesita tener declaraciones de importación en los otros archivos (para Alamofire en este ejemplo), pero es una solución limpia en términos de segregación de interfaces en mi opinión.

Creo que este enfoque funciona igual de bien con clases externas y propias.