问题: I get that with delegates you are delegating a task to another object. I guess I just don't understand why this is beneficial.

最佳答案:

简而言之, UITableView专注通用功能的实现 -- 你不必考虑如何才能让table view滚动, 不必考虑记录数过多怎么办(怎么重用cell) 不必判断是哪个cell被点击了. UITableView会告诉你, 你只要老老实实的实现它指定的接口, 做一个合格的delegate, 实现与UI无关的业务逻辑就行了. UITableView和Delegate(通常是ViewController) 各司其职 --- 做一件事, 并把它做好.

原文如下:

[–] 4 points 13 hours ago 

UITableView is the best example to think of here to get your head around it.

What does the UITableView do?

• Display "cell" objects in a vertical stack
• Scroll to allow displaying more cells than the visible area could hold
• Reuse cells so that we don't run out of memory
• Identify cells that are touched

And other things but that's a good place to start. Now you want to build an application that displays data in cells that can scroll on multiple pages without using delegates how would you create your own UITableView to be able to do this? I'm sure the basics above would be easy to implement and figure out, but what about these questions:

• Would you pass in the cell object to draw?
• And the data objects to fill out that cell, (array, dictionary, custom class)?
• What if you needed to display more than 1 type of cell?
• How would you deal with the action(s) to perform on a cell when it's tapped?
• Do all cells perform the same action?

Is the version of UITableVIew that you are building even re-usable at this point? Not really, you'd have so much branching logic that your nice clean re-usable UITableView that just deals with laying things out on screen is a big buggy mess with no easy way to test it.

Now if you just focused only on the core features of what a UITableView does and instead delegated out the application logic to someone else you can see how clean and testable your UITableView becomes. All it cares about is putting some view it's given by someone else on screen at a specific location, allowing the views it's displaying to scroll, and telling whoever cares when a cell get's touched. This version of UITableView can be used by anyone for any purpose to display any data. It doesn't care what that data is, it doesn't care what happens when a cell is touched. It just delegates those decisions to someone else.

What delegates allow you to do is build re-usable code blocks that do "one" thing and do it well. They let the application logic be placed in less generic re-usable objects and allow developers to basically forget about all of the complexity of what the re-usable object is doing. How often do you concern yourself with the scrolling behavior of a UITableView? You don't, you know it'll work and do what it's told.