Quale è più efficiente; una sottoclasse di UITableViewController per più scopi o più sottoclassi ciascuno per uno scopo?

2

Supponiamo che abbia due viste (Vista tabella per esempio) che mi piacerebbe che facessero cose diverse; ognuno carica dati diversi ma i comportamenti sono simili per la maggior parte del par tranne che accade quando una cella viene toccata, ad esempio. Uno mostra un elenco di voci, un altro un elenco di utenti, un altro un elenco di commenti, ecc. Posso scrivere una sottoclasse di UITableViewControler per tutti con una variabile flag per distinguere la logica o una sottoclasse separata per ciascun controller di visualizzazione.

Sto cercando di capire cosa è meglio. So che i blocchi più piccoli sono più facili da eseguire il debug, ecc. Ma ancora una volta, è una sorta di codice ripetuto per avere più della stessa classe standardizzata. Quale sarebbe un buon approccio qui?

    
posta TheeBen 03.03.2017 - 04:47
fonte

2 risposte

1

Il principio Open-Closed dovrebbe essere la tua guida qui. Avere una singola sottoclasse UITableViewController con una "variabile di flag" che viene poi controllata in tutto il posto all'interno della classe è una scelta di design molto scarsa. Ogni volta che desideri aggiungere un nuovo controller di visualizzazione tabella nella tua app, finirai per scavare nella classe MonsterTableViewController e aggiungere ancora un altro flag e un gruppo di switch / se controlli per gestire le differenze. La tua classe non è "aperta per estensione e chiusa per la modifica" in questo modo.

Se trovi che hai, ad esempio, 3-4 comportamenti diversi quando una cella viene toccata, ma tutto il resto del codice è lo stesso, quindi fornisci al tuo controller di visualizzazione un delegato o una chiusura che rappresenta Strategia (secondo lo schema della strategia) utilizzato quando un elemento viene TAPpato e lo fornisce sia in fase di costruzione, sia se stai usando uno storyboard da costruire, quindi nella preparazione precedente per i successivi.

Si può arrivare addirittura a rendere generica la classe di strategia e tenere la matrice di oggetti che vengono utilizzati per l'origine dati. Quindi fornire una chiusura per cellForRowAtIndexPath e didSelect. Oppure puoi seguire il percorso più tradizionale e rendere la classe di strategia un protocollo e avere diverse implementazioni.

Si noti che ricorda molto come UITableViewDatasource e UITableViewDelegate sono già gestiti. Ciò che molte persone finiscono per fare è solo avere un sacco di classi che implementano entrambi questi protocolli. Passa un'istanza di una di queste classi a UITableViewController per gestire i dettagli.

risposta data 04.07.2017 - 03:25
fonte
2

Dovresti provare ad avere classi separate per ogni controller di visualizzazione e una classe generica (o più) per il codice comune, che sarà riutilizzata dalle classi specifiche. Evita il più possibile la ripetizione del codice.

Nota: questo non è assolutamente speciale per ios, oggettivo-c, rapido o UITableViewController - è un principio generale nella progettazione OO.

    
risposta data 03.03.2017 - 07:49
fonte