首先我们要熟记几个原则
第一个原则: 单一职责
一个类应该只做一类事情, 一个方法最多只做一件事情
邮件类就应该只发送邮件，但是不关心发给谁，你告诉我发给谁我就发给谁
如果你发现你在Mail.php里 使用了 User::find(), 这样的语句存在的时候，就真的是在乱搞了
第二个原则: 不要做超前的设计
就是，你不要觉得“这代码以后应该会用到，先留着吧”
这样是不正确的，用到的时候再加吧，不要做这些提前的过度设计（当然，一个良好的可拓展的系统是以后方便拓展的基础啦）
第三个原则：三次原则
如果一段代码，你在一个地方写了一次，两个地方写的时候你在想，我是不是该封装到另外的方法或者抽到另外的类里去呢
答案是最好在你第三次重复它的时候才抽出
（当然这个为啥是三次，我的理解是：重复一两次（当然不是大段大段的，一般是一个小的转换代码这样的几行）对于阅读来讲比打开另外的一个类，一个文件去找这个方法要方便得多）
（也不是很冗余，所以说在第三次重复的时候才抽出去，这只是一个折中的点吧）
这三个原则是比较基础的了, 还有很多当然是可以让你代码写得更好的原则定义，可以去翻阅大神的一些文章
另外说一下我个人写代码的一些思路，及从大神同事那里学到的一些技巧.
写代码的方法，可以考虑以树状结构来写
什么是树状结构呢？
比如我们现在写一个公司内部用的图书馆,其中的一个逻辑是拥有一本书的人通过表单创建一条贡献,那么这是一个action要完成的业务逻辑
我们第一步，对它进行拆分：
1. 验证输入
2. 拿输入的ISBN从豆瓣取书的信息
3. 创建Book实体并写入数据库
4. 创建Contribution实体并写入数据库
5. 响应
这是 postContributon 这个动作所包含的最顶层的逻辑划分
我们的代码第一步已经完成了, 下一步怎么办？给每个逻辑起个名, 当然了，第1与第5就不用了，框架封装的比较好了.
于是代码变成了这样, 这时候 getBookFromDouban createContribution这些方法都还没有写的，所以参数设计并不一定正确，后续发现不对再回来修改.
然后你再去创建这些子方法，记住：创建子逻辑方法的时候同样使用这个方式去拆分
那其实这就是我说的树状结构的写法：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 这里就不讲了大家都熟悉
然后在 Manager （或者AuthorizeManager）里应该有一些方法，比如：login(CredentialInterface $credential), getAuthorizedUser(); ....
所以文件与职责已经拆分完成了,过了一个月后，老大说：我要加一个微信登录！！！！
没问题，不就是加一个Credential 与 Authenticator 就完事了，互不干扰.
[疑问] 怎么做：这个是动词，所以不应该以动词来为类命名
就是说不能有一个类叫：Login.php。怎么做，这里有5种做法，所以就是说有5种授权方式，最终落地为：5个授权器（名称好难听）
