BadSmell重构和设计的标准.docx

Bad Smell重构和设计的标准。——与其无尽的等待完美的设计，不如立刻着手实现可行的设计，然后再在设计出现臭味的时候重构实现！?食品有做得好不好之分。其中一个重要的指标就是保质期。好的食品，保质期就长，坏的食品保质期就短。对于代码来说也一样。也有一个保质能力的问题。好的代码，入口芬芳。坏的代码早早就变质了，而且随着时间的推移越来越臭，直到最后，我们只好把它扔掉，虽然它也曾经是我们花钱买来的…… 比如说，我们接到一个项目，我们经过思考，获得了一个可行的设计方案，然后着手实现。此时，可能有一个小功能。我们是使用GOF23个设计模式，用n个类实现呢，还是立刻用10来行代码解决呢？我们应该选择“可到达目标的简单方案”。这是XP方法的一大原则。现在，这一段代码散发着well-smell，过了几天，我们又增加几项功能。再看到这段代码时，它已经散发出bad smell了。也许是因为，我们的代码大大增加了，一段语意含混不清的代码，让阅读者头晕。也许是因为，出现了大量代码的重复，或者是我们这一段不太“香”的代码被很多代码所调用。当你学会用挑剔的眼光审视自己所写的文字时，会发现将一段文字反复读上五六遍，每次都会找到新的问题。重构，也就是对既有代码设计的改善，要求你首先知道什么样的代码需要改善。重构目录可以帮助你获得这样的知识，但是你的情况可能与目录中所看到的不同。所以，了解常见的设计问题非常必要，这样你才能在自己的代码中识别出这些问题。下面列举出几种Bad Smell(代码的坏味道)：1.Duplicated Code(重复的代码) 臭味行列中首当其冲的就是Duplicated Code。如果你在一个以上的地点看到相同的程序结构，那么当可肯定：设法将它们合而为一，程序会变得更好。最单纯的Duplicated Code就是［同一个class内的两个方法含有相同表达式(expression)］。这时候你需要做的就是采用Extract Method提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。另一种常见情况就是[两个互为兄弟(sibling)的subclasses内含有相同表达式]。要避免这种情况，只需要对两个classes都使用 Extract Method，然后再对被提炼出的代码使用Pull Up Method，将它推入superclass内。如果代码之间只是类似，并非完全相同，那么就得运用Extract Method将相似部分和差异部分割开，构成单独一个方法。然后你可能发现或许可以运用Form Template Method获得一个Template Method设计模式。如果有些方法以不同的算法做相同的事，你可以择定其中较清晰的一个，并使用Substitute Algorithm将其它方法的算法替换掉。如果两个毫不相关的classes内出现Duplicated Code，你应该考虑对其中一个使用Extract Class，将重复代码提炼到一个独立class中，然后在另一个class内使用这个新class。但是，重复代码所在的方法也可能的确只应该属于某个 class，另一个class只能调用它，抑或这个方法可能属于第三个class，而另两个classes应该引用这第三个class。你必须决定这个方法放在哪儿最合适，并确保它被安置后就不会再在其它任何地方出现。 2.Long Method(过长方法) 拥有[短方法](short methods)的对象会活得比较好、比较长。不熟悉面向对象技术的人，常常觉得对象程序中只有无穷无尽的delegation(委托)，根本没有进行任何计算。和此类程序共同生活数年之后，你才会知道，这些小小方法有多大价值。［间接层］所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型方法支持的。很久以前程序员就已认识到：程序愈长愈难理解。早期的编程语言中，［子程序调用动作］需要额外开销，这使得做你们不太乐意使用small method，现代OO语言几乎已经完全免除了进程内的[方法调用动作额外开销]。不过代码阅读者还是得多费力气，因为他必须经常转换上下文去看看子程序做了什么。某些开发环境允许用户同时看到两个方法，这可以帮助你省去部分麻烦，但是让small method容易理解的真正关键在于一个好名字。如果你能给方法起个好名字，读者就可以通过名字了解方法的作用，根本不必去看其中写了些什么。最终的效果是：你应该更积极进取地分解方法。我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立的方法中，并以其用途(而非实现手法)命名。我们可以对一组或甚至短短一行代码做这件事。哪怕替换后的方法调用动作比方法自身还长，只要方法名称能够解释其用途，我们也该毫不犹豫地那么做。关