When should data source and delegate be different objects?

Question

Under what conditions is it necessary to have separate objects for data source and delegate? Most applications I've come across make a point to have self.currentView.delegate = self. Is it solely for readability and sectioning off code?

Answer 1

A data source is simply a kind of delegate with a different name and a different set of responsibilities. Apple explains this nicely in the docs:

A data source is like a delegate except that, instead of being delegated control of the user interface, it is delegated control of data.

Separating the two roles allows developers to specify different objects for each when it suits them rather than forcing them to use a single object for two related but different tasks. It's never necessary to use different objects for the two roles, but it can sometimes be convenient.

Consider a view controller containing a table that can switch between several "modes," where each mode displays the same items with different details. One way to implement such a table is to do everything in the view controller, but then you end up with code like:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *theCell = nil;
    switch (self.selectedMode) {
        case kFirstMode: {
            // set up the kind of cell required for mode 1
            break;
        }
        case kSecondMode: {
            // set up the kind of cell required for mode 2
            break;
        }
        //...and so on...
    }
    return theCell;
}

You can smell the negative code review already, right?

Another, arguably better approach is to create separate data source objects for each mode. When the user switches modes, you just swap in a new data source that knows how to display the data for the selected mode. This scheme works even better when the different modes display completely different data items rather than different aspects of the same items.

Answer 2

Pointing to self (as "the view controller") is certainly popular and I believe this is because its just "easier" to write all your code in one place.

If you follow any architecture design patterns, most will want you to create objects with single responsibility. This means your class is responsible for one thing and one thing only.

You can read more about this pattern here: http://en.wikipedia.org/wiki/Single_responsibility_principle

Putting that into practice, you would have a view controller this is responsible only for the layout of your view and an additional data source class that is only responsible for loading data.

Following these design patterns usually means you have neater, more maintainable code with reduced cyclomatic complexity.

A class that conforms to any type of "Data Source" protocol (delegate) is also reusable. It means you could use the same data logic across multiple view controllers without code duplication.