对optional 属性的思考

我们现在假设有一个API需求一个类叫做联系人，那么我们建一个：

struct Contact {
    let id:String
    let firstName:String
    let lastName:String
    var type:ContactType
    //phoneNumber is optional only for FaceBook type
    var phoneNumber: String?
    //userName is optional only for AddressBook type
    var userName:String?
    
}

enum ContactType{
    case AddressBook
    case FaceBook
}

表面上看起来不错，完美实现了联系人这个类的需求，但是这个类存在一个比较大的问题在于，这个类的使用者是存在潜在可能性给这个类传一个错误的值得。尽管我们为userName这个属性写了documentation表示如果你想传给我一个来自facebook的联系人的话，那么这个属性并不是optional的。然而，作为一个Dev你自己也知道documentation是写给经理和security team看的，并不会有什么开发者真的会去看documentation。那么这样的话，API在接受了错误的类以后肯定会返回错误的。那么这个时候，你这个类的使用者多半是会骂娘的，甚至严重一点的会对你们公司产生一些负面的评价类似什么垃圾公司出的SDK连最基本的binding都不做。看起来毫无道理，但是现实却是大部分程序员都觉得自己才是最屌的，出了问题肯定都是别人傻逼，然后跟上面汇报的时候只会说你看出这个SDK的公司连最基本的安全性检查都没有，现在App出问题了。

那么既然it happens，只能自己解决这样的问题，现在先看一种最直觉和最容易想到的解决方案：

enum Contact{
    case AddressBook(AddressBookContact)
    case FaceBook(FaceBookContact)
}

extension Contact {
    var id:String {
        switch self {
        case .AddressBook(let contact):
            return contact.id
        case .FaceBook(let contact):
            return contact.id
        }
    }
    
    var firstName:String {
        switch self {
        case .AddressBook(let contact):
            return contact.firstName
        case .FaceBook(let contact):
            return contact.firstName
        }
    }
    
    var lastName:String {
        switch self {
        case .AddressBook(let contact):
            return contact.lastName
        case .FaceBook(let contact):
            return contact.lastName
        }
    }
}

struct FaceBookContact {
    let id:String
    let firstName:String
    let lastName:String
    var userName:String
}

struct AddressBookContact {
    let id:String
    let firstName:String
    let lastName:String
    var phoneNumber: String
}

So far so good, 沾沾自喜五分钟以后觉得可以收工回家了，觉得今晚可以睡个好觉了。表面上来看，的确是这样的，问题解决了，暗坑也被填平了，共有属性也可以直接访问了，完美。
然而不幸的事情发生了，过了几天，产品跑过来跟你说，是这样的，我需要给联系人增加几个共有属性，于是你发现，卧槽我竟然在不断重写同样的东西！这样一想，岂不是会被end dev笑死？不行，如果作为一个程序员最基本的权利-懒惰都无法保证，那跟咸鱼有什么区别？显然，要解决的是Contact enum中每一个共有属性都需要写一次switch表达式的问题：

enum Contact{
    case AddressBook(AddressBookContact)
    case FaceBook(FaceBookContact)
}

extension Contact {
    private func value(of name:String)->Any? {
        let reflectedSelf = Mirror(reflecting:self)
        let propertys = Mirror(reflecting: reflectedSelf.children.first!.value)
        for child in propertys.children {
            if child.label == name {
                return child.value
            }
        }
        return nil
    }
    var id:String{return value(of: #function) as! String}
    var firstName:String{return value(of: #function) as! String}
    var lastName:String{return value(of: #function) as! String}
}

上面这段代码唯一值得解释一下的应该是#function，实际上呢，这个就是外层函数的函数名，比如：

func method1(_ name:String){}
func methods(){
    //这个时候#function就是methods
    method1(#function)
}

在swift之中，closure和function是没有本质区别的，或者说closure是一种特殊的function。 因此，对于 var id {} 这种结构，id就变成了closure的名字，也就是外层函数的名字。

这个解决方案到这里，的确是解决了所有的问题，但是这个方案显得很不自然，可读性很差，可维护性也不高。那么反思一些是不是走错了方向？毕竟如果开始的方向就不对，那么走再远也是没有意义的。其实这个问题用POP是可以很轻松的解决的：

protocol ContactCore {
    var id:String{get}
    var firstName:String{get}
    var lastName:String{get}
}

protocol AddressBoonContact:ContactCore{
    var phoneNum:String{get}
}

protocol FaceBookContact:ContactCore {
    var userName:String{get}
}

//用法范例
var contacts:[ContactCore] = []

for contact in contacts {
    if contact is AddressBoonContact {
        
    }else if contact is FaceBookContact {
        
    }
}