【问题标题】:Implicitly Unwrapped Optional in method signature方法签名中的隐式解包可选
【发布时间】:2015-10-13 10:26:06
【问题描述】:

从 API 设计的角度来看,在我看来,在方法签名中使用隐式解包可选 (IUO) 只会有利于方法代码(不必解包)而不是调用者。

open source code 为例:

class func getStationDataWithSuccess(success: ((metaData: NSData!) -> Void)) {

        if useLocalStations {
            getDataFromFileWithSuccess() { data in
                success(metaData: data)
            }
        } else {
            loadDataFromURL(NSURL(string: stationDataURL)!) { data, error in
                if let urlData = data {
                    success(metaData: urlData)
                }
            }
        }
    }

当 metaData 可以是可选的时,我认为没有任何价值被声明为 IUO,或者是否有理由将这个方法参数声明为这样?

因此,从 API 设计的角度来看,在我看来 Optional 应该总是比 IUO 更好的做法(基于具体原因,而不是意见)

【问题讨论】:

  • 不完全重复(您在询问方法中的参数),但相关:stackoverflow.com/questions/24006975/…
  • 谢谢@SteveWilford。如果您查看答案,您会发现在普通 API 中没有提及原因,如示例代码所示 IUO 优于 Optional。

标签: swift optional


【解决方案1】:

在 API 设计方面,我相信这里接受的答案大部分也回答了您的问题:

In Swift, what does the ! symbol mean in a function signature?

此外,可以在此处的前几个答案中找到一些良好的一般用例和隐式解包选项的动机:

Why create "Implicitly Unwrapped Optionals"?

【讨论】:

  • 我在发布之前阅读了这两篇文章。他们谈到了 ObjC 桥接等,但没有回答为什么在普通 API 设计中 optional 并不比 IUO 更好。
  • 我不认为 IUO 在普通 API 设计中更好,而是在上面第一个答案中提到的上下文中,但是我会更多地研究它并尝试想出一个更好的回答。
  • 我真的认为除了互操作性之外,在方法签名中使用 IUO 没有任何充分的理由。您链接的开源 API 在其方法签名中没有任何用处,并且将功能相同而不会被隐式解包。有关互操作性的更多信息:developer.apple.com/library/ios/documentation/Swift/Conceptual/…
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-05-22
  • 2013-03-21
  • 2015-10-24
  • 2014-11-24
相关资源
最近更新 更多