代码坏味道，未完。。

最新推荐文章于 2024-03-12 07:56:25 发布

子不语Iori

最新推荐文章于 2024-03-12 07:56:25 发布

阅读量460

点赞数

本文链接：https://blog.csdn.net/ipenrojun/article/details/8443533

版权

正在学习《重构-改善既有代码的设计》，so。。。。做下笔记，以便反复理解

1、重复代码
（1）同一个类的两个函数有相同的表达式。提取重复的代码，让这两个地方都调度提取的那段代码。
（2）两个互为兄弟的子类里面有相同的表达式。那么两个子类都要提取重复的代码，然后用Pull up把重复的代码推入超类。
（3）两个毫不相关的类出现重复的代码。应该将重复的代码提炼到一个独立的类中，或许就在其中一个类中。
2、过长函数
拥有短函数的对象会活得比较长，比较好。使用小函数真正的关键在于使用一个好名字。条件表达式和循环常常也是提炼的信号，你可以使用Decompose Conditional处理条件表达式。至于循环，你应该将循环和其内的代码提炼到一个独立的函数中
3、过大的类
如果想利用单个类做太多的事情，其内部就会出现太多实例变量。一旦如此重复代码就接踵而至了。
4、过长的参数列
5、发散式变化
   我们希望软件能够更容易被修改，一旦需要修改，我们希望能够跳到系统的某一点，只在该处做修改。当你看着一个类说：如果要加入一个数据库，我必须修改这三个函数；如果新出现一种金融工具，我必须修改这四个函数。那么此时也许将这个对象分成两个会更好，这么一来每个对象就可以只因一种变化而需要修改。针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化。

6、霰弹式修改
    如果没遇到某种变化，你都必须在许多不同的类做出许多小的修改。那么就是霰弹式修改。如果需要修改的代码散步四处，你不但很难找到他们。也很容易忘记某个重要的修改。这种情况下你应该把所有需要修改的代码放进同一个类。如果眼下没有合适的类可以安置这些代码，那就创造一个。
发散式变化：一个类受多种变化影响。霰弹式变化：一种变化引发多个类相应修改。这两种情况下你都会希望整理代码，让“外界变化” 与 “需要修改的类” 趋于一对一的对应

7、依恋情结
   函数对某个类的兴趣高过于对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。无数次经验里，我们看到某个函数为了计算某个值，从另一个对象哪儿调用几乎半打的取值函数。疗法:将这个函数移植另一个地点。