什么是反模式？
我正在学习模式和反模式。 我对模式有一个清晰的认识，但是我没有得到反模式。 networking和维基百科的定义使我困惑不已。
有人可以用简单的语言向我解释什么是反模式吗？ 什么目的？ 他们在做什么？ 这是一件坏事还是好事？
反模式是软件开发中的某些模式，被认为是不好的编程实践。
与常见问题已经forms化的常用方法devise模式相反，通常被认为是一种很好的开发实践，反模式是相反的，是不可取的。
例如，在面向对象的编程中，想法是将软件分成称为对象的小块。 面向对象编程中的一种反模式是一个上帝对象 ，它执行许多function，将更好地分离成不同的对象。
例如：
class GodObject { function PerformInitialization() {} function ReadFromFile() {} function WriteToFile() {} function DisplayToScreen() {} function PerformCalculation() {} function ValidateInput() {} // and so on... // } 上面的例子有一个对象，它可以做所有事情 。 在面向对象的编程中，最好对不同的对象有明确的责任，以保持代码的耦合性，最终保持更好的可维护性：
class FileInputOutput { function ReadFromFile() {} function WriteToFile() {} } class UserInputOutput { function DisplayToScreen() {} function ValidateInput() {} } class Logic { function PerformInitialization() {} function PerformCalculation() {} }
底线是，有很好的方法来开发软件，常用的模式（ devise模式 ），但也有办法软件开发和实施，这可能会导致问题。 被认为是不好的软件开发实践的模式是反模式。
模式是如何解决某个阶级的问题的一个想法。 反模式是如何不解决它的想法，因为实现这个想法会导致糟糕的devise。
一个例子：一个“模式”将使用一个函数的代码重用，“反模式”将使用复制粘贴相同的。 两者都解决相同的问题，但使用函数通常会导致比复制粘贴更可读和可维护的代码。
每当我听到有关反模式的消息，我都会回忆起另一个术语， devise气味。
“devise的气味是devise中的某些结构，表明违反了基本的devise原则，并对devise质量产生了负面影响”（摘自“软件devise的重构：pipe理技术债务”）
根据违反devise原则分类的devise气味有很多种：
抽象的气味
缺less抽象：当使用数据或编码string而不是创build类或接口时会产生这种气味。
命令性抽象：当一个操作转化为一个类时，会产生这种气味。
不完全抽象：当抽象不完全支持互补或相互关联的方法时，会产生这种气味。
多方面的抽象：当一个抽象有多个责任分配给它时，就会产生这种气味。
不必要的抽象：当一个实际上不需要（因此可以避免）的抽象被引入到软件devise中时，就会产生这种气味。
未使用的抽象：当没有使用抽象（不是直接使用或不可达）时，会产生这种气味。
重复抽象：当两个或两个以上的抽象具有相同的名称或相同的实现或两者兼而有之时，会产生这种气味。
封装的气味
Deficient Encapsulation（封闭不足）：当一个或多个抽象成员声明的可访问性比实际要求更宽容时，会发生这种气味。
泄漏封装：当抽象通过其公共接口“暴露”或“泄漏”实现细节时，会产生这种气味。
缺less封装：当实现变体未封装在抽象或层次结构中时，会出现这种气味。
未开发的封装：当客户端代码使用显式types检查（使用链接的if-else或switch语句检查对象的types）而不是利用已经封装在层次结构中的types的变体时，会产生这种气味。
模块化的气味
破碎的模块化：当理想的数据和/或方法被本地化为单一的抽象时，这种气味就会分离出来并传播到多个抽象中。
模块化不足：当没有完全分解的抽象存在时，会产生这种气味，进一步的分解可能会减小其体积，实施复杂性或两者兼而有之。
循环依赖模块化：当两个或两个以上的抽象直接或间接相互依赖（在抽象之间build立紧密耦合）时，会产生这种气味。
类似Hub的模块化：当抽象具有大量其他抽象的依赖（包括传入和传出）时，就会产生这种气味。
层次气味
缺less层次结构：当代码段使用条件逻辑（通常与“标记types”结合使用）明确地pipe理行为变化时，会产生这种气味，其中层次结构可能已经创build并用于封装这些变化。
不必要的层次结构：当整个inheritance层次结构是不必要的时候就会产生这种气味，表明inheritance已经被不必要地应用于特定的devise环境。
无形的层次结构：当层次结构中的types之间存在不必要的重复时，会产生这种气味。
宽层次结构：当inheritance层次结构太“宽”时，会产生这种气味，表明中间types可能会丢失。
推测层级（Speculative Hierarchy）：当一种层级中的一种或多种types被推测性地提供时（即基于想象的需求而不是真实的需求），就会产生这种气味。
深层次结构：当inheritance层次“过深”时会产生这种气味。
叛逆层次：当一个子types拒绝超types提供的方法时，就会产生这种气味。
破碎的层次结构：当超types及其子类概念上不共享“IS-A”关系导致可替代性损坏时，会产生这种气味。
多path层次结构：当一个子types直接和间接地从一个超typesinheritance，导致层次结构中不必要的inheritancepath时，会产生这种气味。
循环层次结构：当层次结构中的超types取决于其任何子types时，会产生这种气味。
上述定义和分类在“重构软件devise气味：pipe理技术债务 ”中有描述。 可以在这里find更多的相关资源。
正如尖锐的说，反模式是不解决问题的一种方式。 但是还有更多的东西可以解决这个问题，这也是经常可以看到的一种方式。
一个常见的方法，使一团糟。 例如像上帝/厨师类（一切）。
如果您真的想学习AntiPatterns，请参阅AntiPatterns （ISBN-13：978-0471197133）。
在其中，他们定义“一个反模式是一种文学forms，描述一个问题的常见解决scheme，产生明显的负面后果”。
所以，如果这是一个不好的编程习惯，但不是一个普通的习惯 – 仅限于一个应用程序，一个公司或一个程序员，它不符合AntiPattern定义的“模式”部分。
就像“devise模式”一样，反模式也是一种解决问题的模板和可重复的方式，但却是非最优和无效的方式。
有趣的是，解决问题的一种既定方式既可以是一种模式，也可以是一种反模式。 辛格尔顿就是最好的例子。 它将出现在两套文献中。
作为非英语母语的人，第一次看到“反模式”，我认为这是反对devise模式的东西，解释了为什么devise模式在某些情况下是不合适的
但令人惊讶的是，反模式是devise模式的补充，告诉你不要在情况A中使用解决schemeA.
简而言之：
devise模式：做
反模式：不要做
如今，软件工程研究人员和从业人员经常互换地使用“反模式”和“嗅觉”两个术语。 但是，它们在概念上是不一样的。 维基百科进入的反模式表明，反模式至less有两个因素不同于不好的做法或坏主意。 反模式是
“尽pipe最初似乎是对问题的适当而有效的回应，但通常使用的过程，结构或行动模式通常具有比有益结果更糟糕的后果。”
它清楚地表明，select一个反模式是相信它是解决问题的一个很好的解决scheme（作为一种模式）。 然而，它带来的是更多的负债而不是利益 另一方面，气味对于软件系统的质量是一个不好的习惯。 例如，辛格尔顿是一种反模式，上帝类（或模块化不足）是一种devise气味。
反模式是人们倾向于错误的方式，或者至less不是那么好的方式。
