I had a discussion with my colleague about the following problem.We have an application where we need filtering functionality. On any main screen within the upper navigation bar, there is a button in the upper right corner. Once you touch that button, an custom written Alert View like view will pop up modally, behind it a semitransparent black overlay view. In that modal view, there is a table view of options, and you can choose one exclusively.  Based on your selection, once this modal view is closed, the list of items in the main view is filtered. It is simply a modally presented filter to filter the main table view.This UI design is dictated by the design department, I cannot do anything about it so let accept this as a premise. Also the main filter button in the navbar will change colours to indicate that the filter is active.The question I have is about implementation. I suggested to my colleague that we create a separate XYZFilter class that will be an instance created by the main view controlleracquire the filtering options    handle saving and restoration of its state - i.e. last filter selectedprovide its two views - the overlay view and the modal view be the datasource for the table in its modal view. For some unknown reason, my colleague was not impressed by that approach at all. He simply wants to do these functionalities in the main view controller, maybe out of being used to do this in the past like that :-/Is there any fundamental problem with my approach? I want tokeep the view controller small, not to have spaghetti codecreate a reusable component (for use outside the project)have more object oriented, decoupled approach.prevent duplication of code as we need the filtering in two different places but it looks the same in both..Any advice?
Getting rid of Massive View Controller in iOS?
object oriented;objective c;cocoa