SwiftUI 1 可选类型与拆包

入门SwiftUI的第五天，作为ObjectiveC老手Swift新手，我用这个系列文章来记录实际项目中遇到的各种问题，这是此系列的第二篇。

SwiftUI 0 从头开始

终于在Swift推出的第六个年头，我开始着手准备将iOS开发技术栈全面从OC迁移到Swift上来，这个决定有些迟缓，但确实到时候了。

时隔两年，再次回顾Reader Prime项目的重构历程，有一点十分坚定，就是对于独立开发者而言，一个好的构架和项目整体的高扩展性，是降低维护成本的必备条件。

进入2018年年尾，iOS开发的环境已经和几年前发生了很大的变化，一方面是iOS系统和Cocoa框架的更新迭代，另一方面是更多优秀的第三方类库的出现，一并提高了iOS项目的开发效率。

五年前我们团队制作第一版倒数日时，并不支持农历，那个时候iOS系统也没有农历的相关接口。14年制作第二版倒数日（iDays）的时候，为了实现农历和公历的双向转换，使用sql数据库存储了前后100年内每日的农历信息，数据容量8Mb左右，增加了软件大小，且限制了年限为 1900年-2100年间。

直到iOS 8.0，iOS系统框架开始才开始支持中国农历的相关计算，我们将系统的相关类进行扩充，以满足我们新产品对农历的需求。

GCDQuene是使用GCD封装的对象化多线程处理模块。

经过三篇文章的铺垫，这里我们终于要讨论到核心部分，就是关于ObjC的消息机制，但不涉及任何关于runtime的内容。

前篇说到我们通过ObjC的Category特性给日常工作增加便捷的实现，这一篇则要从语言设计角度，跟大家分享一些思考。

不要忽视interface

ObjC的@interface设计，跟Java和C#真的很像，但又略有不同，相比之下Java和C#则像是一个模子刻出来的。ObjC的特点十分明显，首先是一般不用写@private和@public来区分私有变量，大部分ObjC开发者甚至都不知道还有这两个关键字，其实Cocoa源代码中也基本没有使用过这种设计，即使ObjC是支持的。

接上篇，其实在接触Ruby不久后，我就萌生了改造ObjC的Cocoa框架的想法。为什么要改造？只为能够提高开发OC项目的效率。同时我也完成了一些改造工作，详见像Ruby一样写ObjC，用block实现链式方法调用

说到改造这个问题，我想起曾经有人说，合格的程序员都会不断追求自动化，不断追求代码的解耦与复用，不断追求拓展技术的边界。我们也往往会从这三个方向找切入口，例如OC和Python一样充斥了一些C语言函数形式的方法或者宏，例如NSLog()、NSLocalizedString()，或是CoreGraphic框架中一系列的C函数，更有甚者GCD（Grand Central Dispatch）完全是C函数代码，但GCD因为把多线程编程做的跟if/else一样好用，所以用多了也都接受了。

从面相对象说起

面向对象的程序设计（Object-Oriented Programming，简记为OOP）这个概念大家都有所耳闻，目前（2017.12）,在Tiobe世界语言排行榜上排前十的语言中，C语言和Assembly language(汇编)外的八种语言均原生支持面向对象的程序设计。