se si nota la duplicazione di ciò che si è scritto o di fronte al codice di scrittura esistente, prendere in considerazione la creazione di un'interfaccia (oggetto, funzioni di impostazione, ecc.) Per gestire queste attività.
vedere DRY (non ripeterlo). ci saranno molte funzionalità duplicate nel momento in cui hai scritto alcune app. è meglio scriverlo una volta e scriverlo correttamente.
Ecco alcune linee guida di alto livello:
non mettere le caratteristiche specifiche app in un'interfaccia comune (invece, utilizzare una sottoclasse condivisa dai 2 progetti)
sempre mantenere la vostra è privo di hack (a meno che tu non abbia a che fare con un problema nelle librerie di sistema). se i clienti (ad es. sottoclassi, chiamanti) hanno bisogno di una soluzione particolare o richiedono un controllo specifico, è meglio farli gestire.
uso asserzioni per assicurare che utilizzano l'interfaccia come previsto, controllare ogni argomento, precondizione/postcondition, lo stato del vostro oggetto, ecc ..
mantenere il vostro oggetti/interfacce molto piccole e gestibile, con una scopo chiaro della loro destinazione d'uso. naturalmente, questo si tradurrà in un numero maggiore di oggetti.
evitare la necessità di utilizzare singleton e dati statici; c'è quasi sempre un modo migliore anche se è semplice come costringere i clienti a creare un'istanza della tua classe.
creare librerie con queste interfacce e dividerle in modo logico.
ora che che è coperto ...
mi piacerebbe cominciare con (potenzialmente multipli) istanze degli oggetti di cui ha bisogno. non c'è nulla nella documentazione che afferma "non si dovrebbero creare più istanze dell'oggetto".
se questo è in qualche modo inadeguata in profilatura, quindi è consigliabile utilizzare un oggetto condiviso che trasmette messaggi agli oggetti (nel vostro app) che hanno bisogno di aggiornamenti.
razionale: le probabilità sono, Apple ha già ottimizzato l'implementazione, quindi non è necessario.
Infine, ho infranto queste linee guida in un'app che richiedeva un sacco di richieste di posizione e visualizzato una tonnellata di informazioni sulla posizione. l'app utilizzava dati statici dietro un'interfaccia che memorizzava il gestore della posizione e la posizione (tra le altre cose). così ho finito per usare dati statici con dati statici privati (nascosti) per ridurre la memoria e le richieste della CPU in questo caso.
Non sono d'accordo con l'uso di singleton. Considero che i singleton sono pessimi come le variabili globali, anzi, sono * variabili * globali ed evitali il più possibile. Ottengo l'argomento "AppDelegate big-ball-of-mud", ma contrasterò se il tuo AppDelegate è sovraccarico, probabilmente dovrai refactoring. Una rapida ricerca di SO mostra che sono [not] (http://stackoverflow.com/questions/228164/on-design-patterns-when-to-use-the-singleton/228380#228380) [solo] (http : //stackoverflow.com/questions/11831/singletons-good-design-or-a-crutch) tenendo questa opinione. –
AppDelegate è esso stesso un singleton. È solo una questione di incapsulamento. Singoli singleton per compiti diversi. Devi evitarli quando puoi, ma a volte sono necessari. Esiste un modo migliore per creare classi come NSFileManager, NSUserDefaults diverse dai singleton? Accedervi tramite AppDelegate? Io non la penso così – gcamp
AppDelegate è di proprietà dell'applicazione UIA, l'oggetto radice per l'intera app e (nella visualizzazione purista) l'unico singleton valido consentito. –