首先我们要熟记几个原则
第一个原则: 单一职责
一个类应该只做一类事情, 一个方法最多只做一件事情
邮件类就应该只发送邮件,但是不关心发给谁,你告诉我发给谁我就发给谁
如果你发现你在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个授权器(名称好难听)
网友评论