理想情况下，我们希望当一个类，一个方法或其他的代码设计完以后，就不用再做修改了。它们应该稳定到不用修改就可以重用。

    现在的情况恰好相反！

    每当我们增加新的形状，都得修改Shape这个类，跟CADApp里面的drawShapes方法。

    怎么让代码稳定（也就是无需修改）？这个问题是个好问题！不过老规矩，先不说，我们以行动回答。

    我们先看看另外一个方法： 当给你一段代码，你怎么知道它是稳定的？

    怎么判断代码的稳定性？

    要判断代码的稳定性，我们可能会这样来判定：先假设一些具体的情况或者需求变动了，然后来看一看，要满足这些新的需求，代码是否需要被修改？

    可惜，这也是一件很麻烦的事，因为有那么多的可能性！我们怎么知道哪个可能性要考虑，哪些不用考虑？

    有个更简单的方法，如果发现说，我们已经第三次修改这些代码了，那我们就认定这些代码是不稳定的。这个方法很“懒惰”，而且“被动”！我们被伤到了，才开始处理状况。不过至少这种方法还是一个很有效的方法。

    此外，还有一个简单，而且“主动”的方法：如果这段代码是不稳定或者有一些潜在问题的，那么代码往往会包含一些明显的痕迹。正如食物要腐坏之前，经常会发出一些异味一样（当然，食物如果有异味了，再怎么处理我们都不想吃了。但是代码可不行。）。我们管这些痕迹叫做“代码异味”。正如并不是所有的食物有异味都不能吃了，但大多数情况下，确实是不能吃了。并不是所有的代码异味都是坏事，但大多数情况下，它们确实是坏事情！因此，当我们感觉出有代码异味时，我们必须小心谨慎的检查了。

    现在，我们来看看上面例子中的代码异味吧！

    示例代码中的代码异味：

    第一种异味：代码用了类别代码（type code）

    这样的异味，是一种严肃的警告：我们的代码可能有许多问题。

    第二种异味：Shape这个类有很多属性有时候是不用的。例如，radius这个属性只有在这个Shape是个圆的时候才用到：

    第三种异味：我们想给p1,p2取个好一点的变量名都做不到，因为不同的情况下，它们有不同的含义：

    第四种异味：drawShapes这个方法里面，有个switch表达式。当我们用到switch（或者一大串的if-then-else-if）时，小心了。switch表达式经常是跟类别代码（type code）同时出现的。