I have a social location based application and I'm in a bit of design conflict that I can't seem to solve or find good information on.Realizing that I have multiple controllers that will similarly access the user's location and load an array of places to be displayed in a table view, I've made a class that has class methods to provide the users location (coordinates and/or reverse-geocoded address), and populate a variably sized NSArray of locations, and other methods that different controllers will use to form their data. Call it SpotsManager. Anticipating future complexity, I have separated SpotManagers duties into 2 separate classes, a SpotLocationManager for wrapping a CLLocationManager and a SpotNetworkManager for wrapping AFNetworking. Do all of these managers give off code smell? It seems excessive, especially compared to most of Apple's sample apps but at the same time, it also seems like beneficially strict organization.To contrast my previous approach, I've branched and made a SpotsList class that knows how to populate its instances with locations. But I question extending this class without creating some God-class. (And [SpotList currentCoordinate] doesn't sound right.)I realize high level design questions provide an opportunity for opinions, so I am specifically asking for an answers that will provide some objectivity and insight into Apple approved design.
Do multiple 'helper' classes conflict with the accepted Apple design scheme?
ios;design patterns;design