Implementing a view controller that can handle two different view types

Sorry if the title sounds confusing, but I couldn't come up with anything better.

Basically I have a view controller that manages a paging scroll view wh开发者_运维百科ich displays several images fetched from a database. I'm new to MVC, and I've tried to write my code following this pattern in the best way I could (my experience is merely based on looking at other people's code and understanding how Apple's classes work, so it may be flawed; I'd be grateful if you could tell me if it is).

This is what I've done: I have a custom view class which contains an UIScrollView, and has two public properties: dataSource and delegate. The data source object has to conform to a protocol I've defined; it returns the number of images and the images themselves. The delegate gets notified when the selected page changes.

I hope I got it right. In any case it works; I'm able to re-implement the data source without any problem (if I need to), and the code that provides the data is separated from the code that displays it.

But now I have a problem: I need to be able to replace the paging scroll view with a CoverFlow-like view duplicating as little code as possible. I know there must be a better way to accomplish this, without having to create another view controller class using this CoverFlow view. The two view classes have similar methods and work in similar ways, so it would make sense to use the same view controller code, instead of duplicating it.

Perhaps I could write an abstract class with generic methods and write two implementations of it, one for the scroll view and one for the CoverFlow view, and then instantiate one of the two in the controller, based on a parameter passed to it. Is this the best way to achieve this?

I hope this is not too confusing and that my approach isn't too much flawed. Thanks.

---

You generally want separate view controllers for separate views because you end up having to check which type of view you are using in every single methods. Then special cases creep in and your code becomes a mess. Besides, you might decide to ditch one view entirely at some point. The more modular the code the better.

The key idea of the Model-View-Controller design is that the views are logically separated from the data model. The model should be the actual core of the program and it should provide data for all the views via the controllers. If you have properly implemented the design, you will not have much customization and little duplication of code because the model will support every possible view with alternation.

In most apps, it is the controllers that are the most customized and you should not spend much effort attempting to prevent duplication. If you find yourself duplicated code between controllers, chances are you have either model or view logic in the controller that shouldn't be there.

In your case, it looks like the datasource object interfaces with your model (like a UITableViewDataSource object does) and since both views use the same logic you can use the same delegate for both views if you define the appropriate protocol. Each view will need a custom delegate to handle customization but that is part of the Delegate design pattern which you should employ.

---

Perhaps I could write an abstract class with generic methods and write two implementations of it, one for the scroll view and one for the CoverFlow view, and then instantiate one of the two in the controller, based on a parameter passed to it. Is this the best way to achieve this?

This sounds like a decent approach.

You could also just implement one view controller that manages both view types, creating the correct view on-demand in loadView.