点击下图,查看大图。
条件语句的“合并理由”也同时指出了“不要合并”的理由:如果你认为你的这些检查的确彼此独立,的确不应该被视为同一次检查,那么就不要使用本项重构。因为在这种情况下,你的代码已经清楚表达出自己的意义。
条件式的两种形式:
此代码的坏味道:
1、它太长,当视频有新类型的时候,它会变得更长。
2、它明显做了不止一件事。
3、它违反了单一权责原则,因为它有好几个修改它的理由。
4、它违反了开放闭合原则,因为每当添加新类型时,必须修改它。不过最麻烦的可能是到处皆有类似结构(_get类型名Rank())的函数。
运行结果:
运行结果:
介绍
accessor:访问者,存储器——在本文翻译为“函数”
dumb:哑
domain class:用以处理业务逻辑
presentation class:用以处理”数据表现形式“
business logic:业务逻辑
unidirectional:单向的
bidirectional:双向的
collection:群集
动机:
“间接访问变量”:支持更灵活的数据获取方式,如lazy Initialization(意思是只有用到值时,才对它进行初始化。)
“直接访问变量”:代码比较容易阅读,不需要停下来说:“啊,这只是个取值函数”。
选择:1、代码规范,按照团队中大多数人的做法去做。
2、个人比较喜欢“直接访问变量”,直到这种方式带来麻烦为止。
martin(作者)的例子:你想获取superclass中的field,却又想在subclass中将该field改为计算后的值,这就最该使用Self Encapsulate Field。
我自己的例子:我一般会把field设置成private,如果外部变量,需要用到此field的时候,我就会用Self Encapsulate Field。或者field的值有变化的时候,用Self Encapsulate Field。
开发初期,我们也许会使用基本数据类型表示简单的行为。例如:你可能会用一个字符串表示电话号码,但是随后可能会出现电话号码的“格式化“,”验证“,”抽取区号“之类的特殊行为。——这时候我们就需要一个新类。
动机:
数组常用于一组相似对象。如果数组中的元素不同,很难明白数组中的第一个元素是人名这样的约定。对象就不同了,可以通过值域名称和函数名称传达这样的信息。——这样无须死记,无须注释。
动机:
索引:
解释:
1、Class承担过多而臃肿不堪——Extract Class将一部分责任分离出去。
2、Class没有承担足够多的责任,不再有单独存在的理由——Inline Class将它融入另一个Class。
3、Class使用另一个Class——Hide Delegate隐藏关系。
4、承接(3),如果Client通过Middle Man 调用很多的Delegate Class的函数(这里只是简单调用,只做跳转,而Middle Man没有做太多的业务逻辑,如10个Delegate Class中的Method对应10个Middle Man的Method)——Remove Middle Man,直接使用Delegate Class,可以部分使用Delegate Method。
类图:
动机:
1、如果一个类与另一个类有高度耦合,我就会Move Method。——class更简单,更干净利落的实现系统交付的任务。
2、移动一些值域,就要检查是否使用另一个类的次数必使用所驻对象的次数还多。
总结