Quali sono le migliori pratiche quando si tratta di estensioni in Swift con in mente la riutilizzabilità?

Question

Quali sono le migliori pratiche quando si tratta di estensioni in Swift con in mente la riutilizzabilità?

#1 da (4 voti)

3

Mi piace il modo rapido di cercare di eliminare le conseguenze indesiderate ovunque sia possibile. Ogni volta che c'è un cambiamento nella lingua che depreca qualcosa che ho fatto per anni, mi costringe a ripensare a ciò che considero la migliore pratica. L'eliminazione di ++, - è stata l'ultima volta che è successo.

Un'area in cui potenzialmente vedo un potenziale enorme per conseguenze indesiderate sono estensioni che vengono automaticamente incluse da file esterni. Se estendo, diciamo UIView da qualche parte, e provo a riutilizzare il codice basandomi su detta estensione in un nuovo progetto, potrei graffiarmi la testa per un po 'quando il mio codice non si sta compilando, e poi devo cercare il file che l'ha introdotto estensione.

La mia domanda è: quali sono le migliori pratiche quando si tratta di estensioni? Ogni estensione dovrebbe vivere in un proprio file? Devo raggrupparli per tipo?

Una delle ragioni che sto chiedendo è pensare che nelle future iterazioni Swift potrebbe richiedere istruzioni implicite di importazione per le estensioni per evitare la situazione descritta sopra. Qualcuno è a conoscenza di qualcosa che rimugina nella comunità Swift?

anti-patterns code-reuse swift-language

posta DudeOnRock 24.03.2016 - 19:24

fonte

1 risposta

Leggi altre domande sui tag anti-patterns code-reuse swift-language

Se un enum viene utilizzato senza operazioni bit a bit e tutti i suoi valori sono predefiniti singolarmente, violano il principio di open closed? Una funzione può essere polimorfa e sovraccaricata?

score 4 · Accepted Answer

Le future iterazioni di Swift potrebbero fare molte cose, ma non vedo nulla sulla roadmap 3.0 ( link ) che suggerisce che dovresti preoccuparti delle importazioni per file. Le importazioni rapide sono un pacchetto piuttosto che un problema a livello di file e sembra improbabile che cambi.

Sembra che la tua attuale confusione derivi dal riutilizzo delle estensioni copiandone l'utilizzo nel pacchetto di ciascuna app. La dipendenza implicita di quel codice su un'estensione nello stesso pacchetto non è quindi ovvia. È possibile risolvere questo problema spostando le estensioni riutilizzabili nel proprio pacchetto. L'utilizzo di tali estensioni richiederebbe quindi un'importazione del pacchetto contenente l'estensione che potrebbe renderlo una dipendenza più evidente e più facile da individuare quando non può essere soddisfatto nella nuova app.

Se stai facendo uso di molte estensioni riusabili potresti prendere in considerazione " Le estensioni rapide non hanno nomi ". Di conseguenza se hai due estensioni che introducono lo stesso metodo su un tipo potresti non essere in grado di utilizzare entrambi i moduli di quelle estensioni. Invece puoi:

Definisci un protocollo per il comportamento che vuoi aggiungere.
Utilizza un'estensione del protocollo per fornire la tua implementazione.
Utilizza un'estensione per fare in modo che il tipo che vuoi estendere adotti questo protocollo.

Puoi quindi disambiguare un tipo che adotta protocolli multipli che definiscono metodi con la stessa firma (vedi link )

es. se avessi i protocolli BackgroundLinearGradientDisplayable e BackgroundRadialGradientDisplayable che entrambi definiscono func setBackgroundGradientColors(start: UIColor, end: UIColor) e UIView sono stati estesi per conformarsi a entrambi i protocolli, allora potrei usare (view as BackgroundGradientDisplayable).setBackgroundGradientColors(start: color1 end: color2) per chiamare un'implementazione di un protocollo specifico. Se dovessi definire solo due estensioni UIView non potrei importare entrambi nello stesso pacchetto.