摘要：坏味道的代码重复代码会自动标注重复的代码。一般都是遇到真实情况后才考虑得到霰弹式修改添加或修改一个功能引发多个类相应修改遇到这种情况可以移动代码，将需要修改的代码都放在同一个类下。被拒绝的遗赠子类应该继承超类的函数和数据。
坏味道的代码 重复代码
idea会自动标注重复的代码。一般重复代码就是可以重构的点。
同一个类的两个函数还有相同的表达式，这时需要提炼出重复代码。
两个互为兄弟的子类内含有相同的表达式，可以提炼相同代码，并放到父类中。
如果两个毫不相关的类中出现重复代码，则可以将重复代码提炼成一个函数放到一个独立类中或者只放在某一个类中（总之要放在合适的地方），然后其他类都去调用这个函数。
过长函数过长的函数。往往代表着功能复杂。可读性差。复用几率低
遵循一个原则,一个函数要尽量短。并以作用命名
保证每个类都只做一件事
过长参数列：用对象做参数来减少参数个数这个我觉得不需要提出来。因为公司一直都是用对象来作为参数的。
发散式变化：添加或修改功能都只改一个类可以将这个类分为多个类。但是这个情况不容易发现。一般都是遇到真实情况后才考虑得到
霰弹式修改：添加或修改一个功能引发多个类相应修改遇到这种情况可以移动代码，将需要修改的代码都放在同一个类下。假如没有这样的类，可以创建一个
依恋情节：一个方法可能会调用多个类的多个数据或方法。而很少调用本类的数据或方法如果该方法只调用了一个类的多个方法。将该方法移到调用类里。
如果该方法调用了多个类的多个方法。将该方法拆解。然后分离到调用类里。
对于总是成堆出现的数据应该封装成一个对象。比如方法参数，就可以封装成对象
switch语句看到switch语句直接就用多态替换。switch本来就是一种重复的语句
冗赘类如果项目中有没用的类
夸夸其谈未来性我们未来一定会做这件事。但是现在用不上。就没必要现在就加上各种特殊情况考虑。做到留有余地就好
比如一个类或方法的唯一服务对象是是测试用例。可以将测试用例和类一并删掉。如果是帮助测试用例得到正确的结果。则可以保留
类中的某个变量可能只针对某种特殊情况。但阅读该代码你会认为这是通常使用的变量。所以额外创建一个类存放该变量
过度耦合的消息链消息链的定义：a对象调用b对象,b对象调用c对象，。。。。这样就形成了消息链
假如a对象发生了变化。
注：不是所有的消息链都是不好的。具体情况具体分析
解决方法：
class Person {
Department _department;
public Department getDepartment(){
return _department;
}
public void setDepartment (Department arg){
_department = arg;
}
}
class Department{
private String _chargeCode;
private Person _manager;
public Department (Person manager){
_manager = manager;
}
public Person getManager{
return _manager;
}
}
如果客户希望知道某人的经历是谁, 他必须先获得Department对象:
manager = john.getDepartment().getManager();
这样的编码就对客户端揭露了Department的工作原理, 于是客户知道:Department用以追踪"经理" 这条信息. 如果对客户端隐藏Department, 可以减少耦合. 为了这一目的, 我在Person中建立一个简单的委托函数:
public Person getManager(){
return _department.getManager();
}
现在,我需要修改Person的所有客户, 让它们改用新函数:
manager = john.getManager();
只要完成了对Department所有函数的委托关系, 并相应修改了Person的所有客户, 我就可以移除Person中的访问函数getDepartment()函数了
中间人 狎昵关系 异曲同工的类如果两个方法做着同一件事，但方法名不一样。就要考虑重新改名字了
不完美的类库如果底层的类库不能满足开发的需要。就用外部方法封装该方法，并添加相关逻辑
纯稚的数据类纯稚的数据类（model）是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
这种类如果get/set方法均是public的，则需要引起注意，应该进行适当的封装，而不是全部公有化。
子类应该继承超类的函数和数据。但如果他们不想或不需要继承所有的函数和数据，则应该为这个子类新建一个兄弟类，把所有用不到的函数和数据放到兄弟类中，他们共享的数据和函数则放到共同的超类中。
过多的注释当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/69691.html
摘要：坏的味道指的是应该被修改，被重构的代码，不具有可读性，复用性，判断逻辑复杂，冗余代码。它们通常能指出代码用途和实现手法之间的语义距离。把所有和这个变量相关的代码新建一个类放入。但这往往不够，请反复运用将某些行为移入类，直到者的协议一致为止。 坏的味道：指的是应该被修改，被重构的代码，不具有可读性，复用性，判断逻辑复杂，冗余代码。应该使用各种重构的手法去改变它！ Duplicated...
摘要：为何重构重构有四大好处重构改进软件设计如果没有重构，程序的设计会逐渐腐败变质。经常性的重构可以帮助维持自己该有的形态。你有一个大型函数，其中对局部变量的使用使你无法采用。将这个函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。 哪有什么天生如此，只是我们天天坚持。 -Zhiyuan 国庆抽出时间来阅读这本从师傅那里借来的书，听说还是程序员的必读书籍。 关于书的高清下载连...
摘要：重构在不改变代码的外在的行为的前提下对代码进行修改最大限度的减少错误的几率本质上，就是代码写好之后修改它的设计。重构可以深入理解代码并且帮助找到。同时重构可以减少引入的机率，方便日后扩展。平行继承目的在于消除类之间的重复代码。 重构 (refactoring) 在不改变代码的外在的行为的前提下 对代码进行修改最大限度的减少错误的几率 本质上， 就是代码写好之后 修改它的设计。 1，书中...
阅读 840·2021-11-15 17:58
阅读 3641·2021-11-12 10:36
阅读 3778·2021-09-22 16:06
阅读 955·2021-09-10 10:50
阅读 1324·2019-08-30 11:19
阅读 3308·2019-08-29 16:26
阅读 927·2019-08-29 10:55
阅读 3340·2019-08-26 13:48
