习语与模式
在编程环境中，习语与 < a href="http://en.wikipedia.org/wiki/Design_Patterns_%28book%29" rel="nofollow noreferrer">模式？
我可以互换使用这些术语，并且通常遵循我听到的最流行的方式，或者在当前对话中最近调用它的方式，例如“复制交换习语”和“单例模式”。
我能想到的最好的区别是，几乎从字面上复制的代码通常被称为模式，而不那么字面意义的代码通常被称为惯用语 ，但这并不总是正确的。这似乎只不过是风格或流行语的差异。这符合您对这些术语的使用方式的看法吗？有语义差异吗？
In the context of programming, how do idioms differ from patterns?
I use the terms interchangeably and normally follow the most popular way I've heard something called, or the way it was called most recently in the current conversation, e.g. "the copy-swap idiom" and "singleton pattern".
The best difference I can come up with is code which is meant to be copied almost literally is more often called pattern while code meant to be taken less literally is more often called idiom, but such isn't even always true. This doesn't seem to be more than a stylistic or buzzword difference. Does that match your perception of how the terms are used? Is there a semantic difference?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
习语是特定于语言的。
模式是独立于语言的设计原则，通常用“模式语言”（统一模板）编写，描述诸如激励环境、优点和优点等内容。缺点、相关模式等
Idioms are language-specific.
Patterns are language-independent design principles, usually written in a "pattern language" (a uniform template) describing things such as the motivating circumstances, pros & cons, related patterns, etc.
当人们从高处观察程序开发（分析师、顾问、学者、方法论大师等）时，看到开发人员在各种情况和环境中一遍又一遍地做同样的事情，那么从观察中获得的情报可以被提炼成一种模式。模式是一种使用代表共同抽象的现有软件工具“做事”的方式。
一些例子：
面向对象编程从开发人员手中夺走了全局变量。对于那些确实仍然需要全局变量但需要一种使其使用看起来干净且面向对象的方法的情况，有单例模式。
有时，您需要创建一个具有多种可能的不同类型之一的新对象，具体取决于某些情况。一种丑陋的方式可能涉及不断扩展的
case语句。以 OO 干净的方式实现此目的的公认“优雅”方法是通过“工厂”或“工厂方法”模式。有时，许多开发人员都以某种方式做事，但这种方式很糟糕，应该不推荐。这可以用反模式形式化。
模式是一种高级的做事方式，并且大多数都是独立于语言的。无论您使用
new Object还是Object.new创建对象，对于该模式来说并不重要。由于模式有点理论化和形式化，因此通常有一个正式的模式（呵呵 - 单词过载！让我们说“模板”）来描述它们。这样的模板可能包括：
习语是低级的东西，通常在语言级别运行。示例：
在 C 中，将数据元素从 src 复制到 dst，同时递增指向两者的指针；它通常是循环完成的。显然，您不会在 Java 或 Object Pascal 中看到这个习惯用法。
是（从内存中粗略引用的）一个 Perl 习惯用法，用于循环输入文件并打印出文件中的所有行。该语句中使用了很多隐式变量。再说一遍，除了 Perl 之外，您不会在任何地方看到这种特殊的语法；但是老 Perl 黑客会快速浏览一下该语句并立即识别出您在做什么。
When people observing program development from On High (Analysts, consultants, academics, methodology gurus, etc) see developers doing the same thing over and over again in various situations and environments, then the intelligence gained from that observation can be distilled into a Pattern. A pattern is a way of "doing things" with the software tools at hand that represent a common abstraction.
Some examples:
OO programming took global variables away from developers. For those cases where they really still need global variables but need a way to make their use look clean and object oriented, there's the Singleton Pattern.
Sometimes you need to create a new object having one of a variety of possible different types, depending on some circumstances. An ugly way might involve an ever-expanding
casestatement. The accepted "elegant" way to achieve this in an OO-clean way is via the "Factory" or "Factory Method" pattern.Sometimes, a lot of developers do things in a certain way but it's a bad way that should be disrecommended. This can be formalized in an antipattern.
Patterns are a high-level way of doing things, and most are language independent. Whether you create your objects with
new ObjectorObject.newis immaterial to the pattern.Since patterns are something a bit theoretical and formal, there is usually a formal pattern (heh - word overload! let's say "template") for their description. Such a template may include:
Idioms are something much lower-level, and usually operate at the language level. Example:
in C copies a data element from
srctodstwhile incrementing the pointers to both; it's usually done in a loop. Obviously, you won't see this idiom in Java or Object Pascal.is (roughly quoted from memory) a Perl idiom for looping over an input file and printing out all lines in the file. There's a lot of implicit variable use in that statement. Again, you won't see this particular syntax anywhere but in Perl; but an old Perl hacker will take a quick look at the statement and immediately recognize what you're doing.
与模式与语言无关的观点相反，Paul Graham 和 Peter Norvig 指出，需要使用模式是您的语言缺少某个功能的标志。 （访问者模式经常被选为最明显的例子。）
我通常认为“模式”和“习语”之间的主要区别在于大小。习惯用法很小，例如“使用保存集合的变量类型的接口”，而模式往往更大。我认为习语的小确实意味着它们通常是特定于语言的（我刚才给出的例子是 Java 习语），但我不认为这是它们的定义特征。
Contrary to the idea that patterns are language agnostic, both Paul Graham and Peter Norvig have suggested that the need to use a pattern is a sign that your language is missing a feature. (Visitor Pattern is often singled out as the most glaring example of this.)
I generally think the main difference between "patterns" and "idioms" to be one of size. An idiom is something small, like "use an interface for the type of a variable that holds a collection" while Patterns tend to be larger. I think the smallness of idioms does mean that they're more often language specific (the example I just gave was a Java idiom), but I don't think of that as their defining characteristic.
因为如果你把 5 个程序员放在一个房间里，他们可能甚至不会就什么是模式达成一致，所以这个问题没有真正的“正确答案”。
我听过一次并且非常喜欢的一种观点（尽管我一生都无法回忆起来源）是，习语是应该在您的语言中使用的东西，或者有某种语言拥有它们。相反，它们是我们使用的技巧，因为我们的语言没有为它们提供直接的原语。例如，Java 中没有单例，但我们可以通过隐藏构造函数并提供 getInstance 方法来模仿它。
另一方面，模式与语言无关（尽管它们通常指特定的范例）。您可能有一些基础设施来支持它们（例如，Spring for MVC），但它们不是也不会是语言构造，但您可能需要该范例中的任何语言都需要它们。
Since if you put 5 programmers in a room they will probably not even agree on what things are patterns, there's no real "right answer" to this.
One opinion that I've heard once and really liked (though can't for the life of me recall the source), is that idioms are things that should probably be in your language or there is some language that has them. Conversely, they are tricks that we use because our language doesn't offer a direct primitive for them. For instance, there's no singleton in Java, but we can mimic it by hiding the constructor and offering a getInstance method.
Patterns, on the other hand, are more language agnostic (though they often refer to a specific paradigm). You may have some infrastructure to support them (e.g., Spring for MVC), but they're not and not going to be language constructs, and yet you could need them in any language from that paradigm.