swift 编程实践
swift 类型推断
毫无疑问，类型推断是现在编程语言的一个重要特性，它让我们的代码更加的简洁易懂。但是swift的类型推断有时候却并非按照我们想像的工作。
比较下面两段代码：
self.performSelector("selector")
和
let selector = "selector"
self.performSelector(selector)
乍看上去两段代码应该是等效的。然而事实却是第一段代码能够顺利编译，第二段代码会编译失败。究其原因，selector的类型会被推断成为String，而performSelector不接受String类型的参数。第一段代码的"selector"会被推断成为Selector类型，因而顺利编译。
目前swift的类型推断系统还不能完全根据上下文得出正确的类型，所以经常使用option查看变量类型是一个推荐的做法
swift 类型推断和编译时间
考虑下面一段代码：
let myCompany = [
"employees": [
"employee 1": ["attribute": "value"],
"employee 2": ["attribute": "value"],
"employee 3": ["attribute": "value"],
"employee 4": ["attribute": "value"],
"employee 5": ["attribute": "value"],
"employee 6": ["attribute": "value"],
"employee 7": ["attribute": "value"],
"employee 8": ["attribute": "value"],
"employee 9": ["attribute": "value"],
"employee 10": ["attribute": "value"],
"employee 11": ["attribute": "value"],
"employee 12": ["attribute": "value"],
"employee 13": ["attribute": "value"],
"employee 14": ["attribute": "value"],
"employee 15": ["attribute": "value"],
"employee 16": ["attribute": "value"],
"employee 17": ["attribute": "value"],
"employee 18": ["attribute": "value"],
"employee 19": ["attribute": "value"],
"employee 20": ["attribute": "value"],
]
]
这一段代码非常简单，但是如果这一段代码需要编译的话，將需要消耗数小时。
如果我们把上面的“String类型”，改成我们自定义的其他类型。编译速度可能会有一些提升。但是当需要推断的类型数量达到一定级别后。编译速度依然是不可接受的。
推测其中的原因，应该是因为每添加一个元素，编译器都需要确切的知道在当前步骤的确切类型。直接导致了编译复杂度的直线上升。
如果我们直接声明出常量myCompany的类型，编译將在毫秒级别时间内完成。
当需要推断的类型比较复杂的时候，直接声明类型將显著提升编译效率
Optional
swift是一种静态强类型语言。其中能体现强类型的特性之一就是optional变量。
在很多语言当中，nil或者null能够赋值给任意的class类型变量。但是swift不行，如果我们想给任何变量赋值nil，我们一定需要将其设置为optional类型。如
let optional: Int? = nil
究其本质，optional其实就是一个enum。其实现为
enum Optional<T> {
case Some(T)
case None
}
"?"其实是苹果为Optional这种特殊的enum提供的语法糖。对于必须有值和可能有值两种情况进行了非常明确的区分。
Enum & Optional
考虑下面一个场景，一个客户需要订火车票去其他城市，但是他有可能订往返票，也有可能订单程票，或者是订联程票。
我们要初始化这一段行程，我们可以用Optional和Enum分别进行设计。
首先，我们定义一个叫做OriginDestination的class，代表单边行程。
设计一，使用Optional：
class Itinerary {
let departing: OriginDestination
let returning: OriginDestination?
let secondDeparting: OriginDestination?
init(departing: OriginDestination, returning: OriginDestination?, secondDeparting: OriginDestination?) {
self.departing = departing
self.returning = returning
self.secondDeparting = secondDeparting
}
}
我们需要通过判断returning和secondDeparting来判断这一段行程的类型。这种设计有几点问题：
- 无法限定外面传进来的值的可能性。比如当returning和secondDeparting同时有值的时候，我们并没有为这种情况定义业务逻辑，也就无法为该种情况提供实现。但是从代码的角度来看，并不能限定这种情况的发生。
- 扩展性，当需要扩展票的类型的时候，这段代码将变的难以扩展和维护。
- 可读性，在不那么了解业务逻辑的情况下，并不能看出returning和secondDeparting二选一的条件。或许只能通过文档约定。
设计二，使用Enum：
enum ItineraryType {
case Oneway(departing: OriginDestination)
case RoundTrip(departing: OriginDestination, returning: OriginDestination)
case OpenJaw(departing: OriginDestination, secondDeparting: OriginDestination)
}
class Itinerary {
let itinerary: ItineraryType
init(itinerary: ItineraryType) {
self.itinerary = itinerary
}
}
这一次设计意图更加明显，直接由ItineraryType来判断行程的类型，并且将对应的值存入对应的case当中。用Optional设计的几点问题就迎刃而解。
推荐使用带值的Enum来实现这种类型多选一，并且有不同的值的组合的需求
Protocol Extension
面向接口编程是OO的设计准则之一，swift中的Protocol约束能力强，并且还能进行扩展。让我们来看一下两组实现：
实现一：
protocol P1 {
func optionalMethod()
}
extension P1 {
func optionalMethod() {
print("default optional method")
}
}
class C1: P1 {
func optionalMethod() {
print("override optional method")
}
}
let c1: P1 = C1()
c1.optionalMethod()
我们可以得到的输出结果为：override optional method
实现二：
protocol P2 {
}
extension P2 {
func optionalMethod() {
print("default optional method")
}
}
class C2: P2 {
func optionalMethod() {
print("override optional method")
}
}
let c2: P2 = C2()
c2.optionalMethod()
我们可以得到的输出结果为：default optional method
以上两组定义实现，区别在于P1中申明了OptionalMethod方法，而P2中没有。而结果是C1成功重写此方法，C2重写失效。
再观察protocol extension，我们容易发现。我们可以很轻松的实现多重继承的关系。而多重继承带来的复杂度相信大家都能够体会。
在足够简单的情况下使用Protocol Extension。不要让一时的方便造成复杂度的上升
