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.