什么是反模式?

发布于 2024-07-25 04:08:28 字数 124 浏览 5 评论 0原文

我正在研究模式和反模式。 我对模式有一个清晰的想法,但我没有反模式。 网络和维基百科的定义让我很困惑。

有人能用简单的语言向我解释什么是反模式吗? 什么目的? 他们在做什么? 这是坏事还是好事?

I am studying patterns and anti-patterns. I have a clear idea about patterns, but I don't get anti-patterns. Definitions from the web and Wikipedia confuse me a lot.

Can anybody explain to me in simple words what an anti-pattern is? What is the purpose? What do they do? Is it a bad thing or good thing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(15

﹎☆浅夏丿初晴 2024-08-01 04:08:28

反模式是软件开发中的某些模式,被认为是不好的编程实践。

设计模式相反,设计模式是解决常见问题的通用方法,这些方法已经形式化并且是反模式通常被认为是一种良好的开发实践,但反模式则相反并且是不可取的。

例如,在面向对象编程中,其思想是将软件分成称为对象的小块。 面向对象编程中的反模式是 God 对象,它执行许多功能,这些功能将更好地分成不同的对象。

例如:

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

最重要的是,有一些好的方法可以使用常用的模式来开发软件(设计模式),但软件开发和实现的某些方式也可能导致问题。 被认为是不良软件开发实践的模式是反模式。

Anti-patterns are certain patterns in software development that are considered bad programming practices.

As opposed to design patterns which are common approaches to common problems which have been formalized and are generally considered a good development practice, anti-patterns are the opposite and are undesirable.

For example, in object-oriented programming, the idea is to separate the software into small pieces called objects. An anti-pattern in object-oriented programming is a God object which performs a lot of functions which would be better separated into different objects.

For example:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

The example above has an object that does everything. In object-oriented programming, it would be preferable to have well-defined responsibilities for different objects to keep the code less coupled and ultimately more maintainable:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

The bottom line is there are good ways to develop software with commonly used patterns (design patterns), but there are also ways software is developed and implemented which can lead to problems. Patterns that are considered bad software development practices are anti-patterns.

耶耶耶 2024-08-01 04:08:28

每当我听到反模式时,我就会想起另一个术语,即。 设计气味。

“设计气味是设计中的某些结构,表明违反了基本设计原则并对设计质量产生负面影响”。(来自“软件设计气味的重构:管理技术债务”)

有许多设计气味根据违反设计原则进行分类:

<强>抽象味道

缺少抽象:当使用大量数据或编码字符串而不是创建类或接口时,就会出现这种味道

命令性抽象。当操作转变为类时,就会出现

这种味道。不完整的抽象:当抽象不完全支持互补或相互关联的方法时,就会出现这种味道。

多方面的抽象,就会出现这种味道。抽象有多个职责分配给它。

不必要的抽象:当软件设计中引入实际上不需要(因此可以避免)的抽象时,就会出现这种味道。

未使用的抽象:当抽象未被使用(未直接使用或不可访问)时,就会出现这种气味。

重复抽象:当两个或多个抽象具有相同的名称或相同的实现或两者都有时,就会出现这种味道。

封装异味

封装不足:当抽象的一个或多个成员声明的可访问性比实际需要的更宽松时,就会出现这种异味。

泄漏封装:当抽象通过其公共接口“暴露”或“泄漏”实现细节时,就会出现这种味道。

缺少封装:当实现变化没有封装在抽象或层次结构中时,就会出现这种味道。

未利用的封装:当客户端代码使用显式类型检查(使用链式 if-else 或 switch 语句来检查对象的类型)而不是利用已封装在层次结构中的类型的变化时,就会出现这种味道。 。

模块化气味

损坏的模块化:当理想情况下应本地化为单个抽象的数据和/或方法被分离并分布在多个抽象中时,就会出现这种气味。

模块化不足:当存在尚未完全分解的抽象时,就会出现这种味道,进一步分解可能会减少其大小、实现复杂性或两者兼而有之。

循环依赖模块化:当两个或多个抽象直接或间接相互依赖(在抽象之间创建紧密耦合)时,就会出现这种味道。

类似集线器的模块化:当抽象与大量其他抽象具有依赖关系(传入和传出)时,就会出现这种味道。

层次结构味道

缺少层次结构:当代码段使用条件逻辑(通常与“标记类型”结合使用)来显式管理层次结构可能具有的行为变化时,就会出现这种味道。被创建并用于封装这些变化。

不必要的层次结构:当整个继承层次结构是不必要的时,就会出现这种味道,表明对于特定的设计上下文不必要地应用了继承。

未分解的层次结构:当层次结构中的类型之间存在不必要的重复时,就会出现这种味道。

宽层次结构:当继承层次结构“太”宽(表明中间类型可能丢失)时,就会出现这种味道。

推测层次结构:当推测性地提供层次结构中的一种或多种类型时(即,基于想象的需求而不是实际的需求),就会出现这种味道。

深层次结构:当继承层次结构“过于”深时,就会出现这种味道。

叛逆的层次结构:当子类型拒绝其超类型提供的方法时,就会出现这种味道。

破坏层次结构:当超类型及其子类型在概念上不共享“IS-A”关系时,就会出现这种味道,从而导致可替代性被破坏。

多路径层次结构:当子类型直接或间接地从超类型继承时,就会出现这种味道,从而导致层次结构中出现不必要的继承路径。

循环层次结构:当层次结构中的超类型依赖于其任何子类型时,就会出现这种味道。


上述定义和分类在“针对软件设计异味的重构:管理技术债务”。 一些更相关的资源可以在此处找到。

Whenever I hear about Anti-patterns, I recollect another term viz. Design smell.

"Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality”. (From "Refactoring for Software Design Smells: Managing technical debt")

There are many design smells classified based on violating design principles:

Abstraction smells

Missing Abstraction: This smell arises when clumps of data or encoded strings are used instead of creating a class or an interface.

Imperative Abstraction: This smell arises when an operation is turned into a class.

Incomplete Abstraction: This smell arises when an abstraction does not support complementary or interrelated methods completely.

Multifaceted Abstraction: This smell arises when an abstraction has more than one responsibility assigned to it.

Unnecessary Abstraction: This smell occurs when an abstraction that is actually not needed (and thus could have been avoided) gets introduced in a software design.

Unutilized Abstraction: This smell arises when an abstraction is left unused (either not directly used or not reachable).

Duplicate Abstraction: This smell arises when two or more abstractions have identical names or identical implementation or both.

Encapsulation smells

Deficient Encapsulation: This smell occurs when the declared accessibility of one or more members of an abstraction is more permissive than actually required.

Leaky Encapsulation: This smell arises when an abstraction “exposes” or “leaks” implementation details through its public interface.

Missing Encapsulation: This smell occurs when implementation variations are not encapsulated within an abstraction or hierarchy.

Unexploited Encapsulation: This smell arises when client code uses explicit type checks (using chained if-else or switch statements that check for the type of the object) instead of exploiting the variation in types already encapsulated within a hierarchy.

Modularization smells

Broken Modularization: This smell arises when data and/or methods that ideally should have been localized into a single abstraction are separated and spread across multiple abstractions.

Insufficient Modularization: This smell arises when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both.

Cyclically-Dependent Modularization: This smell arises when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions).

Hub-Like Modularization: This smell arises when an abstraction has dependencies (both incoming and outgoing) with a large number of other abstractions.

Hierarchy smells

Missing Hierarchy: This smell arises when a code segment uses conditional logic (typically in conjunction with “tagged types”) to explicitly manage variation in behavior where a hierarchy could have been created and used to encapsulate those variations.

Unnecessary Hierarchy: This smell arises when the whole inheritance hierarchy is unnecessary, indicating that inheritance has been applied needlessly for the particular design context.

Unfactored Hierarchy: This smell arises when there is unnecessary duplication among types in a hierarchy.

Wide Hierarchy: This smell arises when an inheritance hierarchy is “too” wide indicating that intermediate types may be missing.

Speculative Hierarchy: This smell arises when one or more types in a hierarchy are provided speculatively (i.e., based on imagined needs rather than real requirements).

Deep Hierarchy: This smell arises when an inheritance hierarchy is “excessively” deep.

Rebellious Hierarchy: This smell arises when a subtype rejects the methods provided by its supertype(s).

Broken Hierarchy: This smell arises when a supertype and its subtype conceptually do not share an “IS- A” relationship resulting in broken substitutability.

Multipath Hierarchy: This smell arises when a subtype inherits both directly as well as indirectly from a supertype leading to unnecessary inheritance paths in the hierarchy.

Cyclic Hierarchy: This smell arises when a supertype in a hierarchy depends on any of its subtypes.


The above definition and classification is described in "Refactoring for software design smells: Managing technical debt". Some more relevant resources could be found here.

总攻大人 2024-08-01 04:08:28

模式是如何解决某个类别的问题的想法。 反模式是一种如何不解决它的想法,因为实施该想法会导致糟糕的设计。

举个例子:“模式”是使用一个函数来重用代码,“反模式”是使用复制粘贴来实现代码重用。 两者都解决相同的问题,但使用函数通常会比复制粘贴产生更具可读性和可维护性的代码。

A pattern is an idea of how to solve a problem of some class. An anti-pattern is an idea of how not to solve it because implementing that idea would result in bad design.

An example: a "pattern" would be to use a function for code reuse, an "anti-pattern" would be to use copy-paste for the same. Both solve the same problem, but using a function usually leads to more readable and maintainable code than copy-paste.

夜司空 2024-08-01 04:08:28

反模式是一种不解决问题的方法。 但它的意义还不止于此:这也是解决问题时经常出现的一种方式。

An anti-pattern is a way of not solving a problem. But there is more to it: it is also a way that can frequently be seen in attempts to solve the problem.

白日梦 2024-08-01 04:08:28

如果您确实想研究 AntiPatterns,请获取《AntiPatterns》一书 (ISBN-13: 978-0471197133)。

在其中,他们定义“反模式是一种文学形式,描述了对产生明显负面后果的问题的常见解决方案。”

因此,如果这是一种糟糕的编程实践,但不是常见的编程实践(出现频率非常有限),则它不符合反模式定义的“模式”部分。

If you really wish to study AntiPatterns, get the book AntiPatterns (ISBN-13: 978-0471197133).

In it, they define "An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."

So, if it's a bad programming practice but not a common one— very limited in frequency of occurrence, it does not meet the "Pattern" part of the AntiPattern definition.

酒中人 2024-08-01 04:08:28

就像设计模式一样,反模式也是一个模板和解决特定问题的可重复方法,但以非最佳且无效的方式。

Just like with a design pattern, an anti-pattern is also a template and a repeatable way of solving a certain problem, but in a non-optimal and ineffective way.

后知后觉 2024-08-01 04:08:28

有趣的是,解决问题的给定方法既可以是模式,也可以是反模式。 Singleton 就是最好的例子。 它会出现在两套文献中。

Interestingly a given way of solving a problem can be both a pattern and an anti-pattern. Singleton is the prime example of this. It will appear in both sets of literature.

你怎么敢 2024-08-01 04:08:28

一种常见的制造混乱的方式。 例如,像 god/kitchensink 类(做所有事情)。

A common way to make a mess. Like the god/kitchensink class (does everything), for example.

罪歌 2024-08-01 04:08:28

反模式设计模式的补充。 反模式是在某种情况下不应使用的模板解决方案。

An anti-pattern is the complement of a design pattern. An anti-pattern is a template solution you should not use in a certain situation.

假扮的天使 2024-08-01 04:08:28

如今,软件工程研究人员和从业者经常互换使用“反模式”和“气味”这两个术语。 然而,它们在概念上并不相同。 维基百科的反模式条目指出,反模式与不良实践或不良想法至少有两个不同之处。 反模式是

“一种常用的过程、结构或行动模式,尽管
最初似乎是对一个问题的适当和有效的回应
问题,通常会带来比有益结果更多的坏后果。”

它清楚地表明,选择反模式是因为相信它是所呈现问题的良好解决方案(作为模式); 然而,它带来的弊大于利。 另一方面,异味只是一种不好的做法,会对软件系统的质量产生负面影响。 例如,Singleton 是一种反模式,God 类(或不足模块化)是一种设计味道。

Today, software engineering researchers and practitioners often use the terms “anti-pattern” and “smell” interchangeably. However, they are conceptually not the same. The Wikipedia entry of anti-pattern states that an anti-pattern is different from a bad practice or a bad idea by at least two factors. An anti-pattern is

"A commonly used process, structure or pattern of action that despite
initially appearing to be an appropriate and effective response to a
problem, typically has more bad consequences than beneficial results.”

It clearly indicates that an anti-pattern is chosen in the belief that it is a good solution (as a pattern) to the presented problem; however, it brings more liabilities than benefits. On the other hand, a smell is simply a bad practice that negatively affects the quality of a software system. For example, Singleton is an anti-pattern and God class (or Insufficient Modularization) is a design smell.

痕至 2024-08-01 04:08:28

因为模式被发现不是被创建的Allen Holub,并且这种发现是通过重复发生的; 如果我们发现了一种可以解决特定问题的模式,但根据领域专家的知识和经验,这种模式不是以正确的方式 - 我们倾向于将其称为反模式

模式:解决常见的、重复出现的问题的正确方法。
anit-pattern:不是解决常见的、重复出现的问题的正确方法。
这两者都基于最新的知识

并且......昨天的害虫实践是明天的反模式Neal Ford,持续交付的工程实践

DevOps世界示例

它曾经是最佳实践(构建共享资源)

在此处输入图像描述

但在世界中,当我们在云中管理资源时,它会引入耦合

因此,现在我们倾向于基于解耦解耦来构建我们的设计解耦 • Michael Nygard • GOTO 2018

因此,对于特定领域(例如 DevOps):

过去:
共享资源==模式==好东西
现在:
共享资源==反模式==坏事
是好事

解耦 == 模式 ==一言以蔽之

更喜欢模式而不是反模式


图片来源:Neal Ford,连续交付的工程实践

Because patterns are discovered not being created Allen Holub and this discovery happens through repetition; if we have discovered a pattern that solves a particular problem but not in the right way according to domain experts knowledge and experience - we tend to call it anti-pattern

pattern: the right way of solving a common, reoccurring problem.
anit-pattern: not the right way of solving a common, reoccurring problem.
both of these based on latest and up to date knowledge

And ... Yesterday's pest practice is tomorrow's anti-pattern Neal Ford, Engineering-Practices-for-Continuous-Delivery

DevOps worlds examples

It used to be a best practice (Architecting Shared Resources)

enter image description here

But in cloud world it introduces coupling when we manage our resources in cloud.

So nowadays we tend to architect our design based on decoupling or uncouple it Uncoupling • Michael Nygard • GOTO 2018

Thus for a specific domain e.g. DevOps:

Past:
Shared Resources == pattern == good thing
Present:
Shared Resources == anti-pattern == bad thing
Decoupling == pattern == good thing

in a word

Prefer pattern over anti-pattern


Image source: Neal Ford, Engineering-Practices-for-Continuous-Delivery

久而酒知 2024-08-01 04:08:28

反模式是人们倾向于以错误的方式进行编程的常见方式,或者至少是不太好的方式。

Anti-patterns are common ways people tend to program the wrong way, or at least the not so good way.

当爱已成负担 2024-08-01 04:08:28

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

有些反模式是显而易见的,但有些则不然。 例如 Singleton,尽管许多人认为它是很好的旧设计模式,但也有其他人不这么认为。

您可以检查问题单例有什么不好?以更好地理解不同的对此的意见。

Any design pattern that is doing more harm than good to the given software development environment would be considered as anti-pattern.

Some anti-pattern are obvious but some are not. For example Singleton, even though many consider it good old design pattern but there are others who don't.

You can check question What is so bad about singletons? to better understand the different opinions on it.

暖阳 2024-08-01 04:08:28

当您以非法方式滥用设计模式,或者您不知道它的实际用法时,有时会使用它。 例如,使用简单类的构建器模式,或者为代码中使用的每个 Active 类定义一个单例实例。

而且它可能超出了设计模式。 例如,将 Java 中的局部变量定义为 Final,或者在您可以简单地检查输入是否为 null 时使用 try / catch 来处理 NullPointerException,或者在使用对象后将其清空(就像您在其他一些中所做的那样)语言),你没有注意到垃圾收集机制,或者调用 system.gc() 来清空内存,以及许多其他误解,这些很可能被视为 Cargo-Cult 现象。

It is sometimes used when you misuse design patterns in an illegal way, or you don't know the actual usage of it. For example, having builder pattern for simple classes, or obsessively defining one singleton instance for each Active class you use in your code.

Also it might be beyond design patterns. For example, defining local variables in Java as final, or using try / catch for NullPointerException when you could simply check input against being null, or nulling objects after they are used (like what you do in some other languages) that you don't notice about garbage collection mechanism, or calling system.gc() to make memory empty, and many other misunderstandings, which are quite likely to be considered as Cargo-Cult phenomena.

血之狂魔 2024-08-01 04:08:28

在基于微服务的领域:

除了数据之外的一切都是微的是一种反模式。
就是说如果每一个东西都合理分解,完全基于DevOps和CI/CD。 也许一些分布式设计模式已经到位,甚至完全复制,但所有服务背后都有一个巨大的数据存储,因此它仍然是一个整体数据结构。

微服务反模式的其他示例

In Microservices based area:

Everything is micro except for data is an anti-pattern.
It means that if every thing is decomposed reasonable and fully based on DevOps and CI/CD. Maybe some distributed design patterns are in place and even fully replicated, but there is one giant data store behind all of the services, so it is still a monolithic data structure.

Other example of Microservices anti-pattern

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文