view层的组织和调用方案笔记

一个不好的View层架构

---

1. 代码混乱不规范
2. 过多继承导致的复杂依赖关系
3. 模块化程度不够高，组件粒度不够细
4. 横向依赖
5. 架构设计失去传承

View代码结构的规定

---

代码结构

细节

1. 所有的属性都使用getter和setter

在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情（勘误1），最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化，则交给getter去做。

2.关于private methods，正常情况下ViewController里面不应该写

正常情况下ViewController里面一般是不会存在private methods的，这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。

MVC的拆分

---

1. 保留最重要的任务，拆分其它不重要的任务

有一件事情Controller肯定逃不掉要做：协调V和M。也就是说，不管怎么拆，协调工作是拆不掉的。
只要不是Controller的核心逻辑，都可以考虑拆出去，然后在架构的时候作为一个独立模块去定义，以及设计实现。

2.拆分后的模块要尽可能提高可复用性，尽量做到DRY

根据第一心法拆开来的东西，很有可能还是强业务相关的，这种情况有的时候无法避免。但我们拆也要拆得好看，拆出来的部分最好能够归成某一类对象，然后最好能够抽象出一个通用逻辑出来，使他能够复用。即使不能抽出通用逻辑，那也尽量抽象出一个protocol，来实现IOP。这里有篇关于IOP的文章，大家看了就明白优越性了。

/// TO-DO