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 controller
- acquire the filtering options
- handle saving and restoration of its state – i.e. last filter selected
- provide 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 to
- keep the view controller small, not to have spaghetti code
- create 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?
3
I don’t see a problem with the approach you outlined. Your problem is one of being able to persuade your colleague that your approach is preferable to theirs. You might try:
- it’s less work, as the same filtering behaviour is needed more than once in different views;
- it’s easier to test, as you don’t have to configure a view controller and all its views just to test some search code.
I think the “reusable component” argument is premature. It’s more persuasive to focus on the reuse problems you currently have (i.e. the two views in the same app), than on speculative future reuse. That can be deleterious, as your colleague might think you’re promoting unnecessary gold-plating work for a problem you don’t know you’ll ever have.