首先我们要熟记几个原则

1. 单一职责 (solid 原则)

• 一个类应该只做一类事情
• 一个方法最多只做一件事情

邮件类就应该只发送邮件，但是不关心发给谁，你告诉我发给谁我就发给谁
如果你发现你在Mail.php里 使用了 User::find() , 这样的语句存在的时候，就真的是在乱搞了 (我也这样觉得)

第二个原则：不要做超前的设计

就是，你不要觉得“这代码以后应该会用到，先留着吧”
这样是不正确的，用到的时候再加吧，不要做这些提前的过度设计
当然，一个良好的可拓展的系统是以后方便拓展的基础啦

第三：三次原则

当然这个为啥是三次，我的理解是：
重复一两次（当然不是大段大段的，一般是一个小的转换代码这样的几行）对于阅读来讲比打开另外的一个类，一个文件去找这个方法要方便得多, 也不是很冗余，所以说在第三次重复的时候才抽出去，这只是一个折中的点吧

这三个原则是比较基础的了
还有很多当然是可以让你代码写得更好的原则定义，可以去翻阅大神的一些文章
另外说一下我个人写代码的一些思路，及从大神同事那里学到的一些技巧

写代码的方法，可以考虑以树状结构来写

什么是树状结构呢？
比如我们现在写一个公司内部用的图书馆
其中的一个逻辑是拥有一本书的人通过表单创建一条贡献
那么这是一个action要完成的业务逻辑
我们第一步，对它进行拆分：

1. 验证输入
2. 拿输入的ISBN从豆瓣取书的信息
3. 创建Book实体并写入数据库
4. 创建Contribution实体并写入数据库
5. 响应

这是 postContributon 这个动作所包含的最顶层的逻辑划分

我们的代码第一步已经完成了
下一步怎么办？给每个逻辑起个名
当然了，第1与第5就不用了，框架封装的比较好了

于是代码变成了这样
这时候 getBookFromDouban createContribution 这些方法都还没有写的，所以参数设计并不一定正确，后续发现不对再回来修改

然后你再去创建这些子方法，记住：创建子逻辑方法的时候同样使用这个方式去拆s分

那其实这就是我说的树状结构的写法：

1. 拆分逻辑变成步骤的注释，
2. 将注释视复杂度变成方法，
3. 递归对方法使用此技巧

下面聊一下如何拆分“类”

做一个复杂模块的时候，很多人一听到这个需求描述的时候就吓晕了
比如，我们现在要做一个登录模块（以微博API的登录为例）
微博API的认证流程分为4-5类（有些已经废弃）

比如：

1. 账号密码登录，
2. 扫码登录，
3. QQ, 支付宝等 OAuth 登录，
4. 短信登录（真的很奇葩），
5. 其它同站业务使用 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吹完了。