Which one is more efficient; a subclass of UITableViewController for multiple purposes or multiple sub classes each for a purpose?

Question

Say I have two views (Table View for example) that I'd like them to do different stuff; each loads different data but behaviors are similar for most par except what happens when a cell tapped for instance. One shows a list of entries, another a list of users, another a list of comments, etc. I can write one subclass of UITableViewControler for all with a flag variable to distinguish the logic or a separate sub class per each view controller.

I am trying to figure out what is best. I know smaller blocks are easier to debug, etc. But yet again, it's sort of repeating code to have multiple of the same class boilerplate. What would a good approach here?

Answer 1

The Open-Closed principle should be your guide here. Having a single UITableViewController subclass with a "flag variable" that is then checked all over the place inside the class is a very poor design choice. Every time you want to add a new table view controller in your app, you will end up having to dig into the MonsterTableViewController class and add yet another flag and a bunch of switch/if checks to handle the differences. Your class isn't "open for extension and closed for modification" that way.

If you find that you have, say, 3-4 different behaviors when a cell is tapped, but all the rest of the code is the same, then provide your view controller with a delegate or closure that represents the Strategy (à la the Strategy pattern) used when an item is tapped and provide that either at construction time, or if you are using a storyboard to construct, then in the previous prepare for segue.

You can even go so far as to make the strategy class generic and have it hold the array of objects that are used for the datasource. Then provide a closure for both the cellForRowAtIndexPath and the didSelect. Or you could go the more traditional route and make the strategy class a protocol and have several implementations.

Note this is very reminiscent of how UITableViewDatasource and UITableViewDelegate are already handled. What many people end up doing is just having a bunch of classes that implement both of those protocols. Pass an instance of one of those classes to the UITableViewController to handle the details.

• https://en.wikipedia.org/wiki/Open/closed_principle
• https://en.wikipedia.org/wiki/Strategy_pattern

Answer 2

You should try to have separate classes for each view controller, and a generic class (or more) for the common code, which will be reused by the specific classes. Avoid as much code repetition as you can.

Note: this is in no way special to ios, objective-c, swift or UITableViewController - it is a general principle in OO design.