扯淡
好的代码 更多的也是为了后期维护,哪怕后期不需要你来维护 ,清晰干爽的代码也会为作者留下好的印象
并且 在工作团队中 可以施加影响力
用封装消灭复杂表达式
业务场景
小江同学想 放学后去同学家看电视 写作业, 可能会比较晚回到家里
他需要向家里人打声招呼 如果家里人不同意的话,他就必须后放学后直接回家
家里人包括 爷爷 奶奶 爸爸 妈妈 哥哥 姐姐(其中一位同意即可)
代码实现之瀑布流
一个条件的成立,需要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