独立日记 2015年1月4日 day14 第二周总结

算了一下,上周工作的时间加起来25个小时,比上周强一点。七天之中有一天是早起的。相对上周来说进步了一点点。下周继续努力!!!

今天的计划:

14:30 ~ 18:00 工作;

19:00 ~ 21:00 更新BitCasual;

21:00 ~ 22:00 运动;

BitCasual更新计划:

1.重构Lua代码;

2.交替出现不同的种类;

3.State Machine和MsgDispatcher;

Jason Ding代码的坏味道:4 Long Parameter List (过长参数列)

因为太长的参数列难以理解, 太多参数会造成前后不一致,不易使用, 而且一旦你需要更多数据,就不得不修改它。如果将对象传递给函数。大多数修改都将没有必要, 因为你很可能只需(在函数内) 添加一两条请求。就能得到更多的数据。

如果向已有的对象发出一条请求就可以取代一个参数, 那么你看应该激活重构手法Replace Parameter With Method(以函数取代参数)。在这里"已有的对象",可能是函数所属类内的一个字段, 也可能是另一个参数。你还可以运用Preserve Whole Object(保持对象的完整性)将来自同一对象的一堆数据收集起来, 并以该对象替换它们。如果某些函数缺乏合理的对象归属。可使用Introduce Parameter Object (引入参数对象)为它们制造出一个"参数对象"。

这里有一个例外: 有时候你明显不希望造成"被调用对象" 与 "较大对象"间的依赖关系。这时候将数据从对象中拆解出来单独作为参数, 也很合情合理。但是请注意其所引发的代价。如果参数列太长或变化太频繁, 你就需要重新考虑自己的依赖结构了。

附上链接4 Long Parameter List (过长参数列)

写给女票的:

外观模式:为系统中的一组接口提供一个统一的接口。外观定义一个高层接口，让子系统更易于使用。

什么时候用？

1.子系统正逐渐变得复杂。应用模式的过程中烟花出许多类。可以使用外观为这些子系统类提供一个较简单的接口。

2.可以使用外观对子系统进行分层。每个子系统级别有一个外观作为入口点。让他们通过其外观进行通信,可以简化它们的依赖关系。

转载请注明地址:独立日记

微信公众号:QWERTeam