冗赘类（Lazy Class）下面首先引用一下《Refactoring to Patterns》中的描述：在描述这种坏味时，Fowler和Beck这样写道：'类如果功能有限，缺乏存在价值，就应该删除。'。经常能够遇到缺乏存在价值的Singleton。事实上，Singleton可能使你的设计过分依赖全局数据，致使代价过高。内联Singleton重构给出了删除Singleton的一种快速而优雅的过程。
类过大（Large Class）下面首先引用一下《Refactoring to Patterns》中的描述：Fowler和Beck提到，存在太多的实例变量，往往说明类的职责太多。一般而言，过大的类通常包含过多的职责。提炼类和提炼子类重构是用来处理这种坏味的主要重构，有助于将职责搬移到其他类中。本书中模式导向的重构都将使用这种重构为类减肥。用Command替换条件调度程序重构将行为提取到Command类中，这样能够极大地减小响应不同请求而执行各种行为的类的体积。用State替换状态改变条件语句重构能够将充满状态转换代码的大类缩减为小类，将职责委托给一族State类。用Interpreter替换隐式语言重构能够通过将大量模仿某种语言的代码转换为小的Interpreter，从而将类大而化小。
分支语句（Switch Statement）下面首先引用一下《Refactoring to Patterns》中的描述：switch语句（或者if...elseif...elseif...结构的等效语句）本身并没有问题。只有在使用这种语句会使设计过度地复杂或者僵硬时，它们才会成为问题。这时，最好将分支语句去除，重构为更基于对象或者多态的解决方案。用Command替换条件调度程序重构描述了如何将大的分支语句分解为一组Command对象，每个Command对象都可以不使用条件逻辑进行查找和调用。将聚集操作搬移到Visitor重构描述了这样一个例子，其中用分支语句保存来自具有不同接口的实例的数据。通过将这段代码重构为使用Visitor，就不需要使用条件逻辑，而且设计也变得更加灵活。
组合爆炸（Combinatorial Explosion）下面首先引用一下《Refactoring to Patterns》中的描述：这种坏味其实是一种不那么明显的重复。当有许多段代码使用不同种类或数量的数据或对象做同样的事情时，就会出现这种坏味。例如，假设你的类中有许多方法执行查询。每个方法都使用特定的条件和数据执行查询。需要支持的特殊查询越多，必须创建的查询方法也就越多。很快，用来处理各种查询方式的方法就会大爆炸。此外，你还使用隐式的查询语言。应用用Interpreter替换隐式语言重构，可以删除所有这些方法，同时去除组合爆炸坏味。
怪异解决方案（Oddball Solution）下面首先引用一下《Refactoring to Patterns》中的描述：在系统中应该始终用一种方式解决一种问题，如果在同一系统中使用不同方式解决同一问题，就称之为怪异或者不一致的解决方案。这种坏味的出现往往说明存在不易察觉的重复代码。要去除这种重复，首先应该确定应该采用哪一种解决方案。在某些情况下，使用率最低的方案可能是优先方案，如果它确实优于大多数时候使用的方案。在确定优先方案后，通常可以应用替换算法F重构得到贯穿系统始终的一致方案。给定一致方案后，就可以将解决方案的所有实例都搬移到一处，从而去除重复。怪异解决方案坏味往往出现在这种情况下：有一种优先方式与一组类通信，而由于类的接口不同，无法以一致的方式与它们通信。在此情况下，考虑应用通过Adapter统一接口重构，生成一个公共接口，用它来一致地与所有类通信。然后，通常会发现有很多方式能够删除重复的处理逻辑。