苹果为了保准UITableView视图的性能，使用了cell的重用机制，cell可以通过重用标示符（reusableIdentifier）进行复用，默认的注册cell和获取cell的方法中，需要传入一个字符串作重用标示符。但这种方式很容易出错，而且使用起来也相当别扭，一种普遍的解决方式，就是直接只用类名作为重用标示符:
123tableview.registerClass(UITableViewCell.self, forCellReuseIdentifier: String(describing: UITableViewCell.self))tableview.dequeueReusableCellWithIdentifier(String(describing: UITableViewCell.self))但这种写法依然颇为繁琐，每次都要传入一个类，并把它转化成字符串。所幸，借助Swift的泛型特性，我们可以有更加优雅的实现方式。
使用协议在使用泛型来优化 TableView Cells 的使用体验这篇文章中，作者详细介绍了如何通过协议+泛型的方式，优化TableView Ce...阅读全文

...阅读全文

2012-01-30
On Extension Method: 扩展方法该如何使用Herb Sutter 曾经有一个观点, 就是一个组件的接口, 不只包括这个组件本身定义的方法, 还包括使用这个组件的客户代码, 比如以这个组件为参数的那些方法. 扩展方法是对Herb Sutter这个观点所做的语法上的支持: 把以这个组件为参数的那些客户代码转变成扩展方法后, 调用时从语法上看起来跟调用这个组件本身定义的方法一模一样了!
———————现实的分割线————————
上面只是一厢情愿的历史溯源. 真实的情况是扩展方法是为了 LINQ 而加进来的, 就为了是表达式看起来干净漂亮些: videoList.Where(video => video.Rate > 18).Select(video => video.Title);
然而这种语法上的便利和优雅, 鼓励了一种原本在面向对象设计中就争论颇多的设计元素的更加随意的使用: 静态方法. 扩展方法只不过是抹了糖的静态方法.
我们需要整理一下扩展方法的应用场景.
 
考察一下LINQ. LINQ 为 IEnumerable 添...阅读全文

本文为《代码整洁之道（Clean Code）》一书的读书笔记。这本书是以Java开发为例，但一些基本的原则是通用的。
书中以Java为例，从命名、函数、类、注释、单元测试、格式、错误处理并发编程等各方面详细介绍了如何让代码变得整洁。整洁的代码有很多特征，其中最重要的，也是一眼能够看出来的，就是整洁的代码都是短小的。诚然短小的代码并不一定都整洁，但整洁的代码一定是短小的，它每份文件的代码量是短小的，每个类是短小的，每个函数是短小的，每个注释是短小的，每个单元测试同样也是短小的。
短小就意味着代码没有多余的内容，意味着代码结构清晰，意味着更好的可读性。
当然短小是有前提的，就是所有的代码命名都是有意义的，类名、函数名、变量名都是有意义的，要在有意义的前提下，尽量做到短小。
有意义的命名一个有意义的命名有以下特点：
名副其实避免误导做有意义的区分，比如同样两只狗，不能叫dog1、dog2这样无意义的区分，可以叫smallDog、bigDog这种有意义。使用读得出来的名称使用可搜索的名称每个概念对应一个词添加有意义的语境，避免添加无用的语境类应该短小关于类的第一条规则是类应该短小。第...阅读全文

2012-01-30
On Test Double: 为什么Mock之争都争错了方向全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个”部分”时所需的依赖如何满足. 解决方案是一组被称为”测试替身(Test Double)”的技术. 我们来看一下这里面具体的问题
为了能编译通过, 我需要依赖被满足为了能正常运行, 我希望依赖的实现不要出错为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为, 并且我可以在不同的测试用例下指定不同的行为在无法方便的观测系统状态变化而做出断言时, 我希望可以退而求其次, 能够得知SUT(System Under Test)正确的与外部依赖进行了交互.解决这些问题的技术手段分别叫做Dummy, Stub, Fake, Mock等. 具体介绍可以参见xUnit Test Patterns. 这些技术对SUT的要求就是其能针对接口进行编程, 以避免Test Double的实现技术过于复杂和困难. 而通常这几种Test Double都可以通过手工编写实现某个接口的替身...阅读全文