代表 – 为什么使用委托和协议而不是在Swift中传递一个实例?

前端之家收集整理的这篇文章主要介绍了代表 – 为什么使用委托和协议而不是在Swift中传递一个实例?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我试图绕过 Swift的视图传递变量,并遇到了相当抽象的协议和代表的概念.

然后,我尝试在第二个视图中存储对第一个视图的引用,并直接调用函数.这似乎工作:

屏幕1

  1. class Screen1: UIViewController {
  2.  
  3. var myName = "Screen1"
  4.  
  5. override func viewDidLoad() {
  6. super.viewDidLoad()
  7. }
  8. //
  9. // checking if the segue to screen 2 is called and then passing a reference
  10. //
  11. override func prepareForSegue(segue: UIStoryboardSegue!,sender: AnyObject!) {
  12. if segue.identifier == "screen2Segue"{
  13. let vc = segue.destinationViewController as Screen2
  14. vc.storedReference = self
  15. }
  16. }
  17.  
  18. func getName() -> String {
  19. return myName
  20. }
  21. }

屏幕2

  1. class Screen2: UIViewController {
  2.  
  3. var storedReference:Screen1!
  4.  
  5. override func viewDidLoad() {
  6. super.viewDidLoad()
  7. }
  8.  
  9. func testReference() {
  10. // calling a function on the stored reference to screen 1
  11. var str = storedReference.getName()
  12. println("Leaving screen 2,going to " + str)
  13. }
  14. }

我的问题:这段代码怎么了?为什么要使用代理和协议,如果你可以直接传递一个引用呢?

也许相关:视图何时被初始化并被全新的视图实例所替代?我在一个旧的实例上调用’getName()’?

协议对于从接口分离实现是有用的,这有助于提高代码的可重用性,可理解性和可测试性.

例如,也许您希望将项目存储在某种列表中. List的一些可能的实现包括基于数组的实现和基于节点(linked-list)的实现.如果要声明一个名为List的协议,并且具有实现该协议的类ArrayList和LinkedList,则需要使用列表(作为参数传递给方法,属性等的变量)的任何内容都可以使用List作为变量类型并且能够在不关心列表是ArrayList还是LinkedList的情况下运行.您可以更改使用哪种类型,或者如何实现它们,并且无论使用它们是什么都不重要,因为只有协议中声明的暴露接口才可见.

协议也可以用于模拟像多继承之类的东西,因为类可以从超类继承,也可以实现一个或多个接口. (例如,蝙蝠既是哺乳动物又是翅膀,所以它可以被表示为继承自实施Winged协议的哺乳动物类的蝙蝠类).

委托模式使用协议将一些责任委托给另一个对象,这对于代码分离和可重用性尤其有用.例如,iOS中的UITableViewDelegate协议允许UITableView通过委托另一个对象来处理事件来对单元格选择等进行反应.这几千个应用程序中可能已经被数百万个对象所使用,没有Apple的开发人员实现了UITableView,而UITableViewDelegate已经知道正在实现协议的对象.

通过在视图控制器之间直接传递引用,您强制第二个完全依赖于第一个.如果您希望更改应用程序的流程,以便可以从其他地方访问第二个视图控制器,则将无法重写该视图控制器以使用新的源代码.如果使用协议,则不需要对第二个视图控制器进行任何更改.

猜你在找的Swift相关文章