首先我们要熟记几个原则
1. 单一职责 (solid 原则)
- 一个类应该只做一类事情
- 一个方法最多只做一件事情
邮件类就应该只发送邮件，但是不关心发给谁，你告诉我发给谁我就发给谁
如果你发现你在Mail.php里 使用了 User::find() , 这样的语句存在的时候，就真的是在乱搞了 (我也这样觉得)
第二个原则：不要做超前的设计
就是，你不要觉得“这代码以后应该会用到，先留着吧”
这样是不正确的，用到的时候再加吧，不要做这些提前的过度设计
当然，一个良好的可拓展的系统是以后方便拓展的基础啦
第三：三次原则
当然这个为啥是三次，我的理解是：
重复一两次（当然不是大段大段的，一般是一个小的转换代码这样的几行）对于阅读来讲比打开另外的一个类，一个文件去找这个方法要方便得多, 也不是很冗余，所以说在第三次重复的时候才抽出去，这只是一个折中的点吧
这三个原则是比较基础的了
还有很多当然是可以让你代码写得更好的原则定义，可以去翻阅大神的一些文章
另外说一下我个人写代码的一些思路，及从大神同事那里学到的一些技巧
写代码的方法，可以考虑以树状结构来写
什么是树状结构呢？
比如我们现在写一个公司内部用的图书馆
其中的一个逻辑是拥有一本书的人通过表单创建一条贡献
那么这是一个action要完成的业务逻辑
我们第一步，对它进行拆分：
- 验证输入
- 拿输入的ISBN从豆瓣取书的信息
- 创建Book实体并写入数据库
- 创建Contribution实体并写入数据库
- 响应
这是 postContributon 这个动作所包含的最顶层的逻辑划分
我们的代码第一步已经完成了
下一步怎么办？给每个逻辑起个名
当然了，第1与第5就不用了，框架封装的比较好了
于是代码变成了这样
这时候 getBookFromDouban createContribution 这些方法都还没有写的，所以参数设计并不一定正确，后续发现不对再回来修改
然后你再去创建这些子方法，记住：创建子逻辑方法的时候同样使用这个方式去拆s分
那其实这就是我说的树状结构的写法：
- 拆分逻辑变成步骤的注释，
- 将注释视复杂度变成方法，
- 递归对方法使用此技巧
下面聊一下如何拆分“类”
做一个复杂模块的时候，很多人一听到这个需求描述的时候就吓晕了
比如，我们现在要做一个登录模块（以微博API的登录为例）
微博API的认证流程分为4-5类（有些已经废弃）
比如：
- 账号密码登录，
- 扫码登录，
- QQ, 支付宝等 OAuth 登录，
- 短信登录（真的很奇葩），
- 其它同站业务使用 access token 登录
每个业务的实现都不一样
怎么办？很多新手已经傻了，打开IDE ， if ($method == 1)..elseif ($method == 2).... N
就开始写了 这是不对的!!!
那么这时候就是理清思路的时候了
几个词：Who, How, What
- 参与者：这个逻辑里的参与者， 凭证(Credential)，会话状态(Session)，用户(User)
- 怎么做：这个是动词，所以不应该以动词来为类命名，最终它的产物应该是设计模式，比如这个模块可以用适配器模式。
- 做什么：它通常定义了整个模块的名称，Login
所以最终的代码可以写成：
- Manager 是主控，负责接收输入，创建对应的登录器
- Authenticator, 完成登录动作，并返回登录用户，保存会话这么一些大局观的动作
- Credential 完全就像模型了（或者实体），只是承载对应授权方式所需要的信息，比如Credential\Password 里应该有用户名与密码，同时 getUsername(), getPassword() 提供这些方法
- 最后两个就不用讲了，User 是同一个，无论 你用什么方式登录，最后都得到的是一个用户，所以它只是最后的产出
- Session 这里就不讲了大家都熟悉
所以文件与职责已经拆分完成了s
过了一个月后，老大说：我要加一个微信登录！！！！
没问题，不就是加一个Credential 与 Authenticator 就完事了，互不干扰
哈哈，NB吹完了。
