But why make UIView subclasses when you don't have to? If I'm just using a tableview, and I need to lay that out, I'm not going to subclass UITableView. I'm just going to add one to my controller or use UITableViewController. If you're already making subclasses of UIView, then yes, do the layout code there, but for many applications this isn't necessary, and there's no where else to put that code.
Well, maybe. UITableViewDelegate and UITableViewDataSource don't have anything to do with the layout of that tableview. But let's say I have a bunch of labels, or textfields, or buttons or imageViews. All of those stock classes will do a pretty good job without subclassing, and for many applications, there's no need to subclass them. If you're doing your layout in code, where else does the layout code go other than the Viewcontroller that manages all those objects.
Comments
But why make UIView subclasses when you don't have to? If I'm just using a tableview, and I need to lay that out, I'm not going to subclass UITableView. I'm just going to add one to my controller or use UITableViewController. If you're already making subclasses of UIView, then yes, do the layout code there, but for many applications this isn't necessary, and there's no where else to put that code.
Specifically UITableView is a bad example here, because UITableView relies heavily on the `UITableViewDelegate` and `UITableViewDataSource`.
For that, though, you should make a separate class for the TableViewModel, to keep that code out of your ViewControllers.
Well, maybe. UITableViewDelegate and UITableViewDataSource don't have anything to do with the layout of that tableview. But let's say I have a bunch of labels, or textfields, or buttons or imageViews. All of those stock classes will do a pretty good job without subclassing, and for many applications, there's no need to subclass them. If you're doing your layout in code, where else does the layout code go other than the Viewcontroller that manages all those objects.