在线这里只有精品,97影视大全免费追剧大全在线观看,91夜夜蜜桃臀一区二区三区

代码的坏味道

Mon, 12 Oct 2009 12:15:00 GMT

《重构》第三章学习�W�记

我们必须培养自己的判断力�Q�来军_��在什么时候进行重构�?

1.1 Duplicate Code�Q�重复代码）

如果你在一个以上地点看到相同的�E�序�l�构�Q�那么将他们合而�ؓ一会更好�?

1.2 Long Method�Q�过长函敎ͼ�

拥有短函数的对象会活得比较好�Q�比较长�?

间接层所能带来的全部益处�Q�解释能力（可读性）�Q�共享能力（重用性）�Q�选择能力�Q�？�Q��?

现在OO 语言基本解决了函数调用所产生的开销�?

�?你应该更�U�极�q�去的分解函数。我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们��把需要说明的东西写进一个函��C��Q��ƈ以其用途（而非实现手法�Q�命名。我们可以对一�l�甚至短短一行代码（拥有复杂逻辑�Q�难以理解）做这件事。哪怕替换后的函数调用动作比函数自��n�q�长�Q�只要函数名�U�能够解释其用途，我们也该毫不犹��U的这么做。关键不在于函数的长度，而在于“做什么”和“如何做”之间的语义距离�?�?

“如何确定该提炼哪一�D�代码？一个很好的技巧是�Q�寻找注释。它们通常是指出“代码用途和实现手法间的语义距离”的信号。如果代码需要用注释来说明其用途，那么��p��考虑把这�D�代码提炼成独立的函敎ͼ��q�且用注释来为此函数命名。�?

复杂条�g式和循环液常常是提炼的信受��?

1.3 Large Class�Q�过大类�Q?/h4>
如果惛_��用单一的class 做太多的事情�Q�其内往往会出现太多的 instance 变量�?
如果class 中拥有太多的代码�Q�也是“代码重复、�؜乱、死亡”的�l�佳滋生炏V�?

1.4 Long Parameter List�Q�过长的参数列表�Q?/h4>
�q�长的��生导致程序难以理解�?

1.5 Divergent Change�Q�发散式变化�Q?/h4>
�?一个class 受多个外界变化的影响 ”，则把�q�多个变化封装成一个新的类。即�?��L��一起变化的东西攑֜�一�?�?
针对外界某一变化所有相应的修改�Q�都应该只发生在单一的class 中，而这�?class 的所有内定w��应该反映该外界变化。�ȝ��思想��是�Q�封装变化。这个地方和设计模式的想法是一致的�?

1.6 Shotgun Surgery�Q�散弹式修改�Q?/h4>
和发散式变化不同�Q�每�ơ遇到变化，都要在多个class 中进行小的修改以响应之。他们分散在多处�Q�很�Ҏ��出错�?
�q�里的主要思想是集中变化�?
散弹式修�Ҏ��的是�Q��?一�U�变化引发多个class 的修�?”，发散式变化指的是�?一个class 受多个外界变化的影响 ”�?
�q�两�U�情况下�Q�通过重构�Q?低쀜外界变化”和“待修改�c�Z��呈一对一关系的理惛_��地�?

1.7 Feature Envy�Q�依恋情节）

某个函数对其他类的数据的兴趣�Q�高�q�对host class 的兴��。即对其他的�cȝ��数据的依赖十分大�?

1.8 Data Clumps�Q�数据惔团）

数据泥团指的是��L��l�定在一起出现的数据�?

一个好的评断方法：删除众多数据中的一��Ҏ��据，其他数据是否是因而失��M��意义�Q�如果他们不再有意义�Q�你应该��Z��们��生一个新的对象�?

形成新的对象后，可以�Ҏ��Feature Envy ��一些操作移��x��对象中�?

1.9 Primitive Obsession�Q�基本型别偏执）

建立多个很小�Q�但是很灉|��的对象�?

1.10 Switch Statements�Q?switch 惊悚现��n�Q?/h4>
使用面向对象�~�程�Q�要��用switch �?case 语句。而是用多态来替换它�?

1.11 Parallel Inheritance Hierarchies�Q��^行��承体�p�）

每当你�ؓ一个class 增加一�?subclass 的时候，必须为另一�?class 增加一�?subclass 。一般这两个 class 的前�~�相同�?

1.12 Lazy Class�Q�冗赘类�Q?/h4>
�c�L��得多余，没有价倹{�?

1.13 Speculative Generality�Q�夸夸其谈未来性）

�q�个往往是过度设计的�l�果�Q�对某种变化的应对，而这�U�变化没有发生�?

1.14 Temporary Field�Q��o��惑的暂时值域�Q?/h4>
变量只在特定的情形下有效�Q�而�ƈ不是所有的情况下有效。很多情况下�Q�这些值域应该不属于此class �Q�而应该单独的提取成新的类�?

1.15 Message Chains�Q�过度耦合的消息链�Q?/h4>
用户向一个对象烦取另一个对象，然后在向后者烦求另一个对象，然后在烦求另一个对象——客户与查找�q�程的航行结构紧密耦合�?

1.16 Middle Man�Q�中间�{手�h�Q?/h4>
对象的基本特征之一��是��装——对外部世界隐藏实现�l�节——封装往往伴随委托。委托的�q�度�q�行�Q�就��D��了Middle Man �?

1.17 Inappropriate Intimacy �Q�亲密关�p�）

两个class 之间的关�p�过于亲密。比如，花大量的旉��探究彼此�?private 成分�?

1.18 Alternative Classes with Different Interface�Q�异曲同工的�c�）

�c�d��不同�Q�但是功能相伹{�?

1.19 Incomplete Library Class�Q�不完美的程序类库）

基础�c�d��无法满��实际的需求�?

1.20 Data Class�Q�纯�E�的数据�c�）

它们拥有一些值域�Q�以及用于访问（��d��Q�这些值域的函敎ͼ�除此之外一无长物�?

1.21 Refused Bequest�Q�被拒绝的遗赠）

子类不像�l�承父类的函数和数据�Q�这往往是��承体�pȝ��错误�?

如果子类复用父类的行为，但又不愿支持父类的接口，�q�种情况下Refused Bequest 的坏味道会很强烈�?

1.22 Comments�Q�过多的注释�Q?/h4>
注释其实是一�U�香呻I��更多的情况下它被用作除臭剂：即代码中出现坏味道（设计�p�糕的代码）�Q�然后用注释“除臭”。这个时候我们应该对�q�些坏味道的代码�q�行重构�Q�然后，你会发现注释变成了多余的�?
当你感觉需要注释，请先��试重构�Q�试着让所有的注释都变得多余——代码本�w�就是自注释的�?
注释可以用来记述“�ؓ什么做某事”、“打��做某事”、“无十��把握的区域”，而不必记录“怎么做”�?/p>

帔R��?/a> 2009-10-12 20:15 发表评论

重构——构筑��试体系

Mon, 12 Oct 2009 12:11:00 GMT

1 构筑��试体系

如果你想�q�行重构�Q�首要前提就是要拥有一个可靠的��试环境�?

“编写优良的��试�E�序�Q�可以极大的提高我的�~�程速度�Q�即使不�q�行重构也是如此。�?

1.1 自我��试代码�Q�Self-testing Code �Q�的价�?/h4>
“Class 应该包含他们自己的测试代码。�?
“每个Class 都有一个测试函敎ͼ��q�用它测试自��p��?Class 。�?
��保所有的��试都完全自动化�Q�让它们��查自��q��试�l�果�?
只要写好一点功能，��q��x��加测试�?
一整组�Q�a suite of �Q�测试就是一个强大的“臭虫”侦��器�Q�能够大大羃减查�䏀�臭虫”所需要的旉��?
“实际上�Q�编写测试代码的最有用时机是在开始编�E�之前。当你需要添加特性的时候，先写相应的测试代码。听��h��ȝ��叛道�Q�其实不然。填写测试代码其实就是问自己�Q�添加这个功能需要做什么。编写测试代码还能��你把注意力集中于接口而非实现上头�Q�永�q�是件好事）。预先写好的��试代码也�ؓ你的工作按上一个明��的�l�束标志�Q�一旦测试代码运行正常，工作��可以结束了。�?
构徏自我��试的代码�?

1.2 JUnit��试框架�Q?Testing Framew �Q?/h4>
频繁的运行测试，每次�~�译��h��试也考虑�q�去�Q�每天至��执行每个测试一�ơ�?
单元��试和功能测�?
“每当你接获臭虫提报�Q�请先撰写一个单元测试来揭发�q�只臭虫。”——如何揭发？�q�里需要根据报告准��定位。单元测试会�Ҏ��有帮助吗�Q?

1.3 ��d��更多的测�?/h4>
“观察Class 该做的所有事情，然后针对��M��一��功能的��M��一�U�可能失败的情况�Q�进行测试。�?
“测试应该是一�U�风险驱动（risk driven �Q�行为，��试的目的是希望扑և�现在或未来的可能出现的错误。�?
“测试的诀�H�是�Q�测试你最担心的部分。�?
�q�点和我目前的想法不大相同。我目前的想法是�Q�测试要对程序做100% 的保证，所以，要测试程序可能行为的每一�U�情况，保证其正��性。按照我的想法，值域的设�|�和讉K��函数也是要测试的。作者的意思是�Q�测试代码要用最低的成本�Q�获取最大的收益。这一点，要我在实际的环境中进行抉择�?
“编写不是十分完��的��试�q�实际运行，好过对完��测试的无尽�{�待。”——我持怀疑态度�?
�q�用��试用例前后执行的函敎ͼ�tearDown �?setUp �Q�保证测试用例之间相互隔��，而非�怺�影响�?
做一个懒惰的�E�序员——�?
考虑可能出错的边界条�Ӟ��把测试火力集中在那儿�?
“测试（优先�Q�可以调高编�E�速度”，�q�一�Ҏ��要在实践中验证一下，如果真是�q�样�Q�那我就要尝试在我们部门推行�q�种�Ҏ��?
“当��试辑ֈ�一定的�E�度后，��试效益会呈现递减态势。”所以，你不要期望通过��试扑և�所有的bug �Q�而是要通过��试�Q�找出绝大多数的 bug �?
�q�个地方其实也符合“二八定律”：�?0% 的测试可以找�?80% �?bug �Q�其余的 80% 的测试可以找出剩下的 20% �?bug 。我们要做的�Q�就是写�q?20% 的测试，而非 100% 的测试�?

帔R��?/a> 2009-10-12 20:11 发表评论

在线这里只有精品,97影视大全免费追剧大全在线观看,91夜夜蜜桃臀一区二区三区

代码的坏味道

1.1 Duplicate Code�Q�重复代码）

1.2 Long Method�Q�过长函敎ͼ�

1.3 Large Class�Q�过大类�Q?/h4> 如果惛_��用单一的class 做太多的事情�Q�其内往往会出现太多的 instance 变量�? 如果class 中拥有太多的代码�Q�也是“代码重复、�؜乱、死亡”的�l�佳滋生炏V�?

1.4 Long Parameter List�Q�过长的参数列表�Q?/h4> �q�长的��生导致程序难以理解�?