1235.jpg
扯淡
好的代码 更多的也是为了后期维护，哪怕后期不需要你来维护 ，清晰干爽的代码也会为作者留下好的印象
并且 在工作团队中 可以施加影响力
用封装消灭复杂表达式
业务场景
小江同学想 放学后去同学家看电视 写作业, 可能会比较晚回到家里
他需要向家里人打声招呼 如果家里人不同意的话，他就必须后放学后直接回家
家里人包括 爷爷 奶奶 爸爸 妈妈 哥哥 姐姐(其中一位同意即可)
代码实现之瀑布流
一个条件的成立，需要n个逻辑组合 或与并非
这样的代码 读起来很不舒服 读的过程中需要重新梳理逻辑
维护一个n年的老项目，到处是这样的长代码 接手的人也不好梳理清楚脉络
然 封装下效果就会好很多
if(father.permit() || mather.permit() || grandPa.permit() || grandMa.permit() || brother.permit() || sister.permit()){
//去同学家写作业
}else{
//放学后回家
}
代码实现之封装
Family family=Family.build(father,mather,grandPa,grandMa,....);
if(family.permit()){
//去同学家写作业
}else{
//放学后回家
}
将上面主干逻辑中的
if(father.permit() || mather.permit() || grandPa.permit() || grandMa.permit() || brother.permit() || sister.permit())
内化到 家庭的 业务域 中
逻辑为:
如果家庭同意..
如果家庭不同意..
代码实现之封装反例 |------| 反对
if(permit()){
//去同学家写作业
}else{
//放学后回家
}
private boolean permit（Father father,Mather mather,GrandPa grandPa,......）{
return father.permit() || mather.permit() || grandPa.permit() || grandMa.permit() || brother.permit() || sister.permit();
}
将逻辑直接私有化 封装起来
1. 私有化后单元测试将覆盖不到
2. 私有化后相同的permit()的业务将散落在系统的各个角落
3. 私有化后permit()的入口不唯一 维护及其不方便
小封装 _
小江同学 完成作业后 才可以吃饭
完成作业的判定规则为 学习时间>1小时
Student xiaojiang;
if(xiaojiang.studyTime > 1){
//完成作业 准备吃饭
}
代码较短 读起来也不费劲
但读起来还是要进行思维转换
学习时间大于1小时 等于 完成作业
-----------------------------------------
class Student{
private String name;
private Integer age;
private Integer studyTime;
private .......;
添加方法 完成作业的判定
public Boolean finished(){
if(this.studyTime > 1){
return Boolean.True;
}
return Boolean.False；
}
}
Student xiaojiang;
if(xiaojiang.finished()){
//完成作业 准备吃饭
}
代码阅读逻辑为:
小江是否完成作业
是: 吃饭
否: 其他
至于 什么是我完成作业 将来业务变成 年龄>18 都没问题
主干逻辑不变，只需修改 学生域下的finished() 的业务表述
总结
用封装消灭长代码 代码可读性提升
恰当业务模型上的对外开发的封装是负责任的封装
私有化的封装是不建议的封装
代码必须私有封装，不私有化无解，不妨跳出当前业务模型，上帝视角判断下当前模型是否合适
一些文件业务等其他 涉密的 要 private
