2018-11-ReadingList

A Better MVC, Part 1: The Problems | Dave DeLong 问题：

1. 违反封装，充斥着大量面条代码
2. Massview View Controller

解决办法： 开发者为了解决上面两个问题通常会使用其它架构方式。但是会增加团队成员的学习成本。系统更新时也有可能需要更多时间来进行适配，同样地，如果你依赖了其它第三库，还需要等得第三库的更新。

A Better MVC, Part 2: Fixing Encapsulation | Dave DeLong 对 View Controller 进行解耦，View Controller 不需要知道其它 View Controller ，做法是生成一个更高层 View Controller，这个 View Controller 不包含其它逻辑，只负责对 View Controller 的跳转进行处理。所有子 View Controller 都通过它来进行跳转。

A Better MVC, Part 3: Fixing Massive View Controller | Dave DeLong 1 View Controller ≠ 1 screen of content 开始写 app 时，我们都会使用一个 View Controller 来表示一个屏幕的内容，但是当 app 变得复杂时，我们可以将某些比较复杂的界面分成多个小的 View Controller。

A Better MVC, Part 4: Future Directions | Dave DeLong 承接上面所说的 1 View Controller ≠ 1 screen of content，单个 cell 也可以使用单个 ViewController 来管理，将 cell 中的逻辑分离出来。 总结：

• 使用 View Controllers 来分解 UI
• 使用 View Controllers 来管理列表控件
• View Controllers 不一定要填充屏幕

A Better MVC, Part 5: An Evolution | Dave DeLong 作者在五个月后又写了一篇关于 MVC 的文章。 MVC 不是一种设计模式，是一种思想，它追求封装，将不同的东西分隔开来。 View Controller 其实不是 Controller，而是 View，它负责的其实是 View 相关的逻辑。 View Controller 应该只负责处理业务逻辑或者传递数据给它包含的 UIViews，不应该两者都包含。 UIViewControllers 应该只负责下面的其中一个部分：

1. 组合 Child View Controller
2. 给自己拥有的 UIViews 填充数据

   So instead of saying a UIViewController should “manage either sequence or UI”, perhaps a better way of saying it would be that a UIViewController should either compose children or put stuff in to UIViews (with the understanding that this is a guideline, and not a rule).

https://www.avanderlee.com/optimization/measure-performance-code/ 检测代码性能: Xcode unit test，playground 和 terminal，playground 因为涉及到 UI 的更新，所以检测到的代码执行时间会其它两个大，其它两个的结果比较接近。

Result<T> 还是 Result<T, E: Error> Result<T, E: Error> 和 Result<T> 的比较。

因为 Swift 并没有提供使用协议类型作为泛型中特化的具体类型的支持，这导致在 API 的强类型严谨性和灵活性上无法取得两端都完美的做法。硬要对比的话，可能 Result<T, E: Error> 对使用者更加友好一些，因为它提供了一个定义错误类型的机会。但是相对地，如果创建者没有掌握好错误类型的程度，而将多层嵌套的错误传递时，反而会增加使用者的负担。同时，由于错误类型被限定，导致 API 的变更要比只定义了结果类型的 Result 困难得多。

关于 Swift defer 的正确使用 defer 的目的就是进行资源清理和避免重复的返回前需要执行的代码，而不是用来以取巧地实现某些功能。这样做只会让代码可读性降低。

实用的可选项（Optional）扩展 Optional 的一些扩展。

Swift Tip: Custom Views Without Subclassing · objc.io 如果只是创建一个 view 后不再进行改变，可以使用一个简单的 functino 来进行创建，而不是自定义一个 subView 。

Swift Tip: Local Struct Definitions · objc.io 为避免占用命名空间，可将只使用一次的类或者结构体放到函数中。

Custom Operators in Swift with considerations for readability - SwiftLee 如果是在频繁使用的可以考虑使用 custom operators，但是需要考虑代码的可读性。

What’s .self, .Type and .Protocol? Understanding Swift Metatypes - SwiftRocks Swift 元类型，介绍了动态元类型 type(of:) 和静态元类型 .self 以及协议的元类型用法。

Avoiding race conditions in Swift 避免竞态条件，讲述两种可能出现竞态条件的情况，多线程和多次请求导致一些不符合预期的情况出现。