题

我学习模式和反图案。我对模式的明确想法，但我不明白的反模式。从网络和维基百科的定义混淆了我很多东西。

任何人都可以用简单的话什么的反模式是向我解释？什么目的？他们在做什么？它是一件坏事还是好事？

有帮助吗？

解决方案

反模式是软件发展的若干模式，被认为是不好的编程习惯。

与之相对设计模式它们是常见问题的常见的方法，其已经形式化和通常被认为是良好的发展实际上，反模式是相反的并且是不希望的。

例如，在面向对象的编程，这个想法是将软件分离成小块称为对象。在面向对象编程的反模式是一个神对象执行很多功能这将被更好地分隔成不同的对象。

例如：

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() {}
}

的底线是有良好的方法来开发与常用的模式（设计模式软件），但也有办法软件开发和实施这可能会导致问题。被认为是不好的软件开发实践模式是反模式。

其他提示

每当我听到关于反模式，我记得另一个术语即。设计气味。

“设计的气味是在设计有一定的结构，指示违反了基本的设计原则和负面影响设计质量。”（摘自‘重构软件设计气味：管理技术债’）

有许多设计气味分类基于违反设计原则：

<强>抽象气味

缺少抽象：此气味，当数据或编码的字符串的团块被用来创建一个类或一个接口代替产生

祈使抽象：当操作被变成一类这种气味产生

不完全抽象：这种气味出现时的抽象不完全支持互补或相互关联的方法

。

多方面抽象：这种气味出现时一个抽象具有分配给它一个以上的责任

。

不必要的抽象：当实际上不需要（并且因此可避免）的抽象的软件设计被引入发生这种气味

未用抽象：这种气味时的抽象闲置（或者不直接使用或不可达）产生

重复的抽象：此气味，当两个或更多个抽象具有相同的名称或相同的实施方案或两者产生

<强>封装气味

亏封装：当一个抽象的一个或多个成员的声明可访问比实际需要更宽容的，会出现此气味

漏封装：这种气味出现时一个抽象“自曝”或“泄漏”的实现细节通过其公共接口

缺少封装：当实现变化不抽象或层次内包封发生这种气味

。

未开发的封装：此气味，当客户端的代码使用明确的类型检查（如果 - 否则，或者使用链切换用于检查对象的类型声明），而不是利用在类型的变化已经封装产生在层次结构中。

<强>模块化气味

破碎的模块化：这种气味时理想地应已被本地化成单个抽象数据和/或方法被分离和在多个抽象传播产生

不足模块化：这种气味时的抽象存在尚未完全分解，并进一步分解可以减少它的尺寸，实现的复杂度，或两者产生

循环地依赖模块化：此气味，当两个或更多的抽象依靠彼此直接或间接（创建抽象之间的紧密耦合）产生

毂形模块化：此气味，当一个抽象具有与大量其他抽象的依赖（传入和传出）产生

<强>层次气味

缺少层次：这种气味当一个代码段使用条件逻辑出现（通常与“标签类型”一起）层次结构可能已创建，和用于封装其中显式地管理在行为变化那些变化。

不必要的层次结构：这种气味当整个继承层次结构是不必要的，指示已针对特定设计上下文不必要施加该继承产生

无分裂层次：这种气味出现时，有层次结构中的类型之间不必要的重复

。

宽层次：这种气味出现时继承层次是“太”宽，指示中间类型可能会丢失

。

投机层次：此SM当推测性地提供在层次结构中的一个或多个类型的ELL出现（即，基于想像需要，而不是真正的要求）。

深层次：这种气味出现时继承层次是“过度”深

。

逆反层次：当一个亚型拒绝通过其超型（S）

提供的方法的这种气味产生。

破碎的层次结构：这种气味出现时超类型和其亚型概念性不共享“IS-A”的关系导致破可替代性

多径层次：这种气味时的子类型包括直接以及间接地从一个超类型导致不必要的继承路径层次结构中的继承产生

循环层次：当在层次结构中的超类型取决于其任何亚型的这种气味产生

上面的定义和分类在描述“重构软件设计气味：管理技术债务”。一些更相关的资源可以发现这里。

一个图案是如何解决某些类的问题的想法。反模式是如何不解决这个问题，因为实施这个想法会导致糟糕的设计想法。

一个例子：一个“模式”是使用代码重用的，“反模式”的功能将是使用复制 - 粘贴对于相同。两者解决同样的问题，但使用的功能通常导致更好的可读性和维护的代码比复制粘贴。

抗图案不是解决问题的方式。但是，还有更多到它：它是还可以经常在试图解决该问题中可以看出的方式

如果你真的想学习反模式，拿书的反模式的（ISBN-13：978-0471197133）。

在它，它们限定“反模式是一种文学形式描述一个通常出现的溶液给产生负面的影响的问题。”

所以，如果这是一个不好的编程习惯，但不是常见的一种，局限于一个应用程序，一个公司或一个程序员，这不符合反模式定义的“模式”的一部分。

一个常见的方式，使一团糟。像神/的KitchenSink类（做一切），例如

这是反模式是设计模式的补码。反模式是你不应该在一定的情况下使用的模板解决方案。

就像用设计模式，一个反模式也是模板和解决某一问题的一个可重复的方式，但在非最佳的和无效的方式。

有趣的是一个给定的解决问题既可以是图案和反模式的方式。单是这最好的例子。它会出现在这两组的文献。

今天，软件工程研究人员和从业人员经常使用的术语“反模式”和“嗅觉”互换。然而，它们在概念上不一样的。反模式的维基百科条目指出，反模式是一个不好的做法，或至少有两个因素一个坏主意不同。反模式是

  

“的常用工艺，结构或动作的模式，尽管   起初看来是一个适当的和有效的反应   问题，通常具有比有益的结果更坏的后果。”

<强>它清楚地表明，抗图案被选择，相信它是一个好的解决方案（作为图案），以所呈现的问题;但是，它带来的好处相比更刑事责任。在另一方面，气味简直是一个不好的做法产生负面影响的软件系统的质量。例如，单件是抗图案和神类（或模块化不足）是一个设计的气味。

反模式是常见的方式人们往往错误的方式进行编程，或者至少不那么好方法。

任何设计模式，它是做弊大于利给定的软件开发环境将被视为反模式。

一些反图案是明显的，但有些则不是。例如辛格尔顿，尽管许多人认为它好老的设计模式，但也有其他人谁不知道。

您可以检查问题什么是坏对单身？，以便更好了解在其上的不同的意见。

像算法可以实现用蛮力解决方案，但你必须付出很多，如果情况变得复杂。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top