Categorie obiettivo-C e classi estese

In primo luogo, l'uso di categorie non riduce la tua classe, ma nasconde quanto grande è la tua classe diffondendo il codice in diversi file. Ci sono alcune volte in cui la tua classe non può essere più piccola (pensa a NSString) perché ha davvero bisogno di molti metodi. Ma sono abbastanza sicuro che la maggior parte delle volte queste grandi classi possono essere più piccole.

Quando una classe è troppo grande, non è solo un problema di leggibilità. Uno dei motivi per cui una classe diventa troppo grande è che viola il principio di singola responsabilità o altri principi di progettazione orientata agli oggetti .

Il mio consiglio è: invece di cercare di ridurre la dimensione dei tuoi file (usando categorie o altri trucchi), dovresti concentrarti sulle responsabilità di classe. Di solito, seguendo semplicemente il Principio di Responsabilità Singola e altre buone pratiche orientate agli oggetti, le classi si dividono naturalmente in altre classi (e non in file). Non solo ridurrà il numero di linee di codice per classi, ma dovrebbe anche portare più classi testabili e riutilizzabili.

Le prime versioni delle mie classi sono state riempite con metodi e definizioni tentacolari per tutto ciò che la classe implementava. Mantenerlo era un inferno. Tutti i miei metodi si stavano perdendo. Erano organizzati dai marchi #pragma, ma il file .m era semplicemente troppo grande. Molti dei miei metodi sarebbero stati parzialmente commentati con nuove funzionalità, penserei di aggiungere un punto ma cambiare idea a metà strada. Era troppo mentale.

Ho riscritto il codice per avere una sottoclasse di view che ha fatto il layout e la gestione di base delle mie sottoview (alcune delle quali erano anche viste personalizzate.) Ho mantenuto le funzionalità davvero ridotte e ho iniziato a sottoclassi la mia vista personalizzata per funzionalità aggiuntive. Ho finito con cose come MenuedCustomView, OverlayCustomView, GradientCustomView. Questo è stato un enorme miglioramento.

In primo luogo, potrei tornare alla sottoclasse di base e affinare davvero le sue responabilità e renderlo super strettamente architettato. In secondo luogo, testare nuove funzionalità era facile e pulito. Vorrei creare una sottoclasse per aggiungere la funzionalità, quindi modificare un simbolo #define nel mio controller, ad esempio TestCustomView o indietro in GradientCustomView o altro. Lo swapping di questa classe era un po 'ingombrante, ma sicuramente funzionava meglio di quando stavo lavorando nella stessa definizione di classe, aggiungendo funzionalità, provandole, ripristinandole, tutte nello stesso file .m. Ho sottoclassi che hanno stub di funzionalità aggiuntive che vorrei aggiungere in futuro, semplicemente non le includo nella mia classe Controller. Quando ho voglia di lavorare no, è super facile da aggiungere al mio progetto.

Poco dopo aver iniziato la sottoclasse di tutto ciò che ho imparato, forse non è sempre la migliore pratica in Objective-C e nel cacao. Sono passato ad aggiungere categorie per molte funzionalità aggiuntive che volevo aggiungere ad una classe. Ovviamente le categorie aggiungono solo metodi e non proprietà, quindi alcune delle funzionalità che stavo aggiungendo erano possibili solo in una sottoclasse. Ora, ho ottenuto una miscela di sottoclassi e categorie per definire i miei oggetti in una gerarchia di file / classi per lo più gestibile e facile da leggere / mantenere.

Mi sono chiesto come Apple mantiene una classe come NSString. È un file .m di grandi dimensioni? Hanno un gruppo di classi ProtoString che aggiungono ciascuna funzionalità separata e quindi le ereditano nell'unica classe NSString? O è un insieme di funzioni base e quindi un gruppo di categorie?

Ho ancora un sacco da imparare sull'architettura di alto livello di una buona applicazione di cacao, ho pensato di condividere la mia progressione.

Parli intorno alle categorie per le tue classi, o per Foundation, ecc.

Per prima cosa, devi decidere se hai davvero bisogno di categorie. In secondo luogo, se prevedi di condividere il tuo codice, devi andare per le convenzioni - in quanto le persone che usano le tue categorie potrebbero non guardare mai nel codice. Se pensi che sia tutto un inferno, chiediti: perché? Probabilmente puoi fare meglio con il codice attuale.

Ad ogni modo, ti consiglio di non accedere direttamente alle variabili di classe usando le categorie - usa proprietà e messaggi, fai attenzione a non cambiare l'oggetto con il tuo codice, se possibile.

Documenta il tuo codice, almeno, le intestazioni: questo potrebbe aiutare chiunque dovrà utilizzarle o rifattorizzarle in seguito.

Una difesa contro le classi sprawling li sta arrotondando in una cartella e un gruppo Xcode. Questo non risolve il problema nel codice, ma aiuta molto a organizzare i file sul disco.

Ad esempio, potresti avere una cartella di categorie UIKit, una cartella per una parte specifica della tua applicazione, ecc.