Devo includere categorie personalizzate nei miei progetti open source?

Question

Sto costruendo un progetto che potrei considerare open source. Ho una categoria UIView che mi dà accesso facile per impostare le coordinate x, y, o la larghezza e lasciato direttamente a un UIView, senza occuparmi del frame. La mia domanda è, dovrei usare tali categorie nel mio progetto se ho intenzione di aprirlo?

Un sacco di progetti avrà una categoria simile con metodi per UIView come

- (void)setLeft:(CGFloat)left; 

o

- (void)setX:(CGFloat)x; 

E il mio capire è che se 2 categorie creare un metodo, si avrà alcuna garanzia su quale sarà chiamato.

Quindi ... cosa dovrei fare? Non usare la categoria e gestisci questo codice fastidioso nel mio progetto open source? Utilizzare le categorie e forse prefisso i nomi dei metodi?

Grazie!

Answer 1

Non preoccupatevi di aggiungere questi metodi.

Risparmiano molto poco la digitazione, il prefisso che dovresti davvero aggiungere sarà brutto, e non aggiungono quasi nessuna reale convenienza mentre il codice scritto contro quell'API aggiunta non è più portabile ai progetti che lo mancano.

Inoltre, disporre di numerosi metodi di convenienza rende molto più difficile la sottoclasse. Quale metodo/i devi sovrascrivere? Qual è il comportamento di KVO? Esiste un metodo primitivo in base al quale tutto viene incanalato o devi davvero ignorare tutto?

I framework generalmente non aggiungono tali API di convenienza perché creano un sacco di "peso" extra all'API mentre incorrono in tutti i problemi sopra menzionati. Tutti questi metodi aggiuntivi sono solo più punti dati per gli sviluppatori che devono imparare, ricordare e spiegare agli altri quando introducono nuove persone nel progetto.

Un'eccezione è rappresentata dalle classi del cluster di classi; NSString, NSArray, ecc. Hanno un insieme fondamentale di metodi primitivi che forniscono tutte le funzionalità necessarie per implementare il resto delle API. Il resto dei metodi sulle classi astratte sono implementati interamente in termini di quei metodi primitivi. Quando sottoclassi, devi solo implementare i primitivi e tutti gli altri comportamenti "funzioneranno". Tuttavia, le sottoclassi sono libere di sovrascrivere qualsiasi dei non primitivi per scopi di ottimizzazione o di personalizzazione (anche se, attenzione, dovresti davvero mantenere il comportamento).

La regola generale è che se un'API di convenienza non salva più di poche righe di codice su base regolare, non ne vale la pena.

Answer 2

Poiché Objective C non supporta gli spazi dei nomi, un modo comune per assicurarsi che il codice sia univoco se si prevede di condividerlo è quello di precedere i metodi con alcune lettere che si riferiscono specificamente al progetto.

Se si rinomina setLeft e setX si chiama LMSetLeft e LMSetX, è necessario ridurre significativamente la possibilità di collisioni.

Questo dovrebbe anche essere un cambiamento davvero semplice purché si utilizzi lo strumento di refactoring dell'IDE.