设计模式真的是语言的弱点吗？
当今的模式是否应该被视为 Java 和 C++ 中的缺陷或缺失功能？
- 子程序是20世纪50年代和60年代机器语言的设计模式。
- 面向对象类是 70 年代的 C 设计模式。
-
访问者、抽象工厂、装饰器和外观是当今 Java 和 C++ 的设计模式。
明天的语言会是什么样子？它们将具有哪些模式？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
一些规范的设计模式——适配器、工厂、命令、访问者等——是其他语言中融入的功能的近似值。我突然想到：
C# 中的事件处理程序是观察者模式的内置版本。考虑一下，如果每次都必须滚动自己的观察者，您将如何在 C# 中连接事件。
访问者模式是多方法的详细近似，消息转发，或者是 模式匹配。
命令模式包装了特定的行为，因此您可以在方法之间传递对象，这或多或少类似于一等函数。
命令模式包装了特定的行为，因此
策略模式允许您动态地将行为插入到对象中，以便您随时可以通过将一种行为替换为另一种行为来修改对象。在函数式编程世界中，我们称之为函数组合。
抽象工厂模式接受一个参数并返回一个工厂作为结果。一般来说，您可以将工厂视为函数的基本包装器（更具体地说，是构造函数的包装器）。因此，您将参数传递给函数并获取函数作为结果，使该模式与柯里化非常相似。
装饰器模式允许您在运行时向对象附加或删除行为。在 JavaScript 中，借助“原型”OO 模型，您可以添加或删除函数，而无需显式实现装饰器模式。
因此，我们有一堆设计模式来模拟其他语言固有的功能。功能嫉妒并不一定表明该语言的弱点 - 这是您需要一遍又一遍地编写的样板代码，这表明了语言的弱点。
Some canonized design patterns -- Adapter, Factory, Command, Visitor, etc -- are approximations of features which are baked into other languages. Off the top of my head:
Event-handlers in C# are baked-in versions of the observer pattern. Think about how you'd wire up events in C# if you had to roll your own observer each time.
Visitor pattern is a verbose approximation of multimethods, message forwarding, or a really weak form of pattern matching.
Command pattern wraps up a particular behavior so you can pass the object between methods, which more or less approximates first-class functions.
Strategy pattern allows you to dynamically insert a behavior into an object, so that at any time you can modify the object by swapping out one behavior with another. In the functional programming world, we call this function composition.
Abstract factory pattern accepts an argument and returns a factory as a result. In general, you can think of factories as basically wrappers around a function (more specifically, wrappers around a constructor). So, you pass arguments to a function and get a function as a result, making this pattern pretty analogous to currying.
Decorator pattern allows you to attach or remove behaviors to an object at runtime. In JavaScript, you can add or remove functions without explicitly implementing the decorator pattern thanks to the "prototype" OO model.
So, we have a bunch of design patterns which emulate features intrinsic to other languages. Feature envy doesn't necessarily indicate a weakness in the language -- it's the boilerplate code that you need to write over and over and over which indicates the language weakness.
我不会称它们为缺陷。
高阶语言比低阶语言处理更高层次的概念。从建筑的角度来思考它。
您可以在炼油厂级别建造一座建筑物，铣削木材，熔炼钢铁，然后以这种方式组装一座建筑物。
您可以购买木板和钢梁，并将它们建造成建筑物。
您可以购买预制墙壁和桁架并将它们建造成建筑物。
您可以购买一栋建筑物，然后从内部开始。
用板和梁建造的建筑物是否缺少预制墙体特征，或者在某些方面存在缺陷？
I wouldn't call them defects.
Higher order languages deal with concepts at a higher level than lower order languages. Think of it in construction terms.
You could build a building at the refinery level, milling lumber, smelting steel, and put together a building that way.
You could purchase boards and steel girders, and construct them into a building.
You could purchase pre-fabricated walls and trusses and construct them into a building.
You could purchase a building and just start with the interior.
Is constructing a building with boards and girders missing the prefabricated wall feature, or defective in some way?
在软件设计中你做三次或多次的每件事都会形成一种模式。
每一次重复。每一次重复。每一次重复。
有些人被封为圣人，名字很酷。这些成为设计模式。有意识地重复。
有些只是“最佳实践”或“这对我有用”。这些是不明确的设计模式。
有些只是“你通常做的事情”。这些设计模式没有任何有意识地意识到你在重复自己。
设计模式与语言弱点或不完整性无关。他们一切都与好的想法有关，并有意识地重复使用。
今天的设计模式并不是通往明天语言的康庄大道。语言范式并不是通过一系列“对先前语言的错误修复”来推进的。如果确实如此，我们就永远不会创建 Visual Basic。
设计模式是比简单的编程语言功能集更大、更广泛的智力工具。
Every single thing that you do three or more times in software designs forms a pattern.
Every repetition. Every repetition. Every repetition.
Some get canonized with cool names. These become Design Patterns. Conscious repetition.
Some are just "best practices" or "this has worked for me." These are design patterns without the clarity.
Some are just "things you usually do." These are design patterns without any conscious recognition that you're repeating yourself.
Design patterns have nothing to do with language weakness or incompleteness. They have everything to do with good ideas, consciously reused.
Today's design patterns are not the royal road to tomorrow's languages. The language paradigm does not advance through a series of "bug fixes to previous languages". If it did, we'd never have created Visual Basic.
And design patterns are a far larger and broader intellectual tool than a simplistic programming language feature set.
我读过类似“你拥有的模式越多，你的语言就越不强大”之类的东西，我发现这个定义非常好。
IMO 的原因很明确：如果您看到重复的模式（或者您必须使用它），则意味着它是逻辑级别上的一种复制粘贴。当然，它不像复制粘贴语句那么糟糕，但它仍然是冗余的。我仍然一次又一次地重复自己。
语言的表现力越强，您就越应该能够通过重用而不是重新实现来捕获和分解这种冗余，并且重用将更容易在源代码中阅读和理解。
每当您发现自己再次做同样的事情（包括例如“好吧……让我们在这里实现一个抽象工厂”）时，这意味着应该在更高的级别上表达。
当然，有时你可以尝试捕捉某些东西的本质，但重用可能比重新实现更难读（我想例如 中 C++“高级”内容的某些部分） ）。在我看来，这是一个明显的迹象，表明该语言表达力不够。
I've read somewhere something like "the more patterns you have, the less powerful your language is" and I find this definition very nice.
The reason is IMO clear: if you see a repeated pattern (or you have to use it) it means that it's a sort of copy'n paste at a logical level. Of course it's not as bad as copy'n paste of statements, but it's still redundancy. I'm still repeating myself again and again.
The more the language is expressive and the more you should be able to capture and factor this redundancy out by transforming it in reuse instead of reimplementation, and the reuse will be easier to read and understand in the source code.
Every time you find yourself doing the same thing once again (including e.g. "ok... let's implement an abstract factory here") it means that's something that should have been expressed at an higher level.
Of course sometimes you can try to capture the essence of something, but the reuse may be uglier to read than the reimplementation (I'm thinking for example to some parts of C++ "high-level" stuff in
<algorithm>). This is IMO a clear sign that the language is not expressive enough.不，他们并没有缺少语言的功能或缺陷。但这些语言应该提供一种为有用模式编写代码的方法，这种方式更容易，而不是困难。这就是该语言提供的功能既可以是好处也可以是障碍的地方。
No, they are not missing features or defects of the languages. But the languages should provide a means for writing the code for a useful pattern easier rather than difficult. That's where the features that are provided by the language can either be a boon or a hindrance.
我认为伊万提出了一个有趣的观点。以他的“子例程”为例。在早期的编程语言中，将参数传递给子例程并返回结果的想法是必须显式编码的。在现代语言中，它是内置的。或者再举一个例子：If/then/else 内置于大多数（如果不是全部）现代语言中。但在我的汇编时代，我必须编写代码来完成这一任务。当然不是很多，但您仍然必须实际编写跳转或 goto 语句才能绕过 else 块。事实上，你必须自己编写这些东西，这意味着不同的程序员会以稍微不同的方式来做，并且存在着无限的诱惑，需要聪明地在这个程序中做一些不同的事情，以使其更高效或获得其他一些东西。所谓的优势。
最近想到的例子是迭代器。您必须用 C++ 和早期版本的 Java 手写它们，但它们内置于 Java 5 中。这可以说是语法糖，您只需创建迭代器函数即可。我个人认为这是一个很好的功能。它能从根本上提高我的生产力吗？不。
我们一直在做的事情是否应该逻辑地内置到语言中以标准化和简化它？一个有趣的问题。我不认为任何人会认真地声称即使他们最喜欢的语言也是完美的并且绝对没有改进的可能。但下一种语言的发展方向是什么？
当然，语言中添加的一些功能是无用的额外包袱。以我的拙见，Java 枚举的作用超出了必要的范围，它们无缘无故地增加了一堆包袱。我确信其他人会不同意并说他们发现它们非常有用。
我没有结论。我只是同意这是一个有趣的问题。
I think Ewan brings up a fascinating point. Take his "subroutine" example. In early programming languages, the idea of passing parameters to a subroutine and returning a result was something that you had to explicitly code. In modern languages, it's built in. Or to take another example: If/then/else is built into most if not all modern languages. But back in my assembler days, I had to write code to accomplish that. Not a lot, of course, but still, you had to actually write the jump or goto statement to go around the else block. And the fact that you had to write these things yourself meant that different programmers would do it in slightly different ways, and there was the endless temptation to be clever and do it a little differently in this program to make it more efficient or gain some other supposed advantage.
The most recent example that comes to mind is iterators. You have to hand-write them in C++ and early versions of Java, but they're built in to Java 5. This is arguably syntactic sugar, you're just as well to simply create iterator functions. Personally I think it's a nice feature. Does it radically improve my productivity? No.
Is there something that we are doing all the time that should logically be built into the language to standardize and simplify it? A fascinating question. I don't suppose that anyone will seriously claim that even their favorite language is perfect and absolutely no improvement is possible. But what will the direction of the next language be?
Surely some features that have been added to languages are useless extra baggage. In my humble opinion, Java enum's do way more than is necessary, they add a bunch of baggage for no good reason. I'm sure others will disagree and say that they find them incredibly useful.
I don't have a conclusion. I just agree that it's a fascinating question.
我认为某些设计模式确实代表了语言的弱点，而新语言将现有模式融入到了一流的公民中。 NOOP 来自 Google。
I think some design patterns do represent language weaknesses and new languages incorporate existing patterns into first class citizens. An example of a new language taking existing design patterns in other languages (dependency injection, immutability, etc.) and incorporating them as first class language level features is NOOP from Google.
我想知道在一种语言变得过于“庞大”之前你可以塞进多少东西。
我喜欢我正在使用的语言足够小，可以一次性保存在我的脑海中。诸如 DI 之类的模式与结构问题有关；那应该是语言的一部分吗？
开发人员真正需要掌握多少语言知识？
就代码契约（要求、确保）而言，如果它是语言的一流部分，那就太好了，但这不是必需的。它仍然可以是图书馆的一部分。
I am wondering how much you can cram into a language before it gets too "large."
I like the language I am working with to be small enough to hold in my head all at once. Patterns such as DI have to do with structural concerns; should that be a part of the language?
How much hand-holding in the language does a developer really need?
In the case of Code Contracts (requires, ensures), it is nice when that is a first-class part of the language, but it is not required. It can still be part of a library.
确实存在促进在语言中使用某些模式的框架，因此它们更多的是一种选择，而不是必须的。对于某个项目，您可能不需要某些模式，因此将其中许多模式合并为主要语言功能只会施加限制，而不是促进富有成效的工作。
Frameworks that facilitate the use of certain patterns in languages do exist, so they're more of a choice rather than a must. There are patterns that for a certain project, you might just not need, so incorporating a lot of them as primary language features would only impose restrictions rather than facilitate productive work.
每种语言都是任意一组设计模式，其语法作为所选模式的符号。对于未选择的模式，您必须在语法的限制范围内进行干预才能表达它们。
大多数语言不允许其语法发生太大变化以吸收更高级别的模式。
一种可以无限地做到这一点的语言将是一种没有严格语法的语言。 （或者以另一种方式，允许无缝吸收任何高级模式）。
参见元语言抽象，
我想到的是scheme/lisp。
each language is an arbitrary set of design patterns with syntax as the notation for the chosen patterns. for the unchosen patterns, you have to meddle within the constraints of the syntax to express them.
most of the languages does not allow its syntax to change much to assimilate higher level patterns.
a language that can do that limitlessly would be one without a rigid syntax. (or in another way, one that allows to seamlessly assimilate any high level pattern).
see metalinguistic abstraction
the one that comes to my mind is scheme/lisp.
设计模式并不是语言的弱点。他们为重复出现的问题提供设计解决方案。
由于许多事情随着时间的推移而不断发展，我认为企业集成模式将会流行。
如果不同的企业应用程序必须进行通信，这些模式提供了最佳的解决方案。
集成样式记录了应用程序集成的不同方式，提供了集成技术的历史记录。所有后续模式都遵循消息传递风格。通道模式描述了消息如何通过消息通道传输。大多数商业和开源消息传递系统都实现了这些模式。消息构造模式描述了在消息传递系统中传输的消息的意图、形式和内容。本节的基本模式是消息模式。路由模式讨论消息如何从发送者路由到正确的接收者。消息路由模式使用来自一个通道的消息，并根据一组条件将其重新发布到另一个通道（通常不进行修改）。本节中介绍的模式是消息路由器模式的特化。转换模式更改消息的内容，例如以适应发送和接收系统使用的不同数据格式。可能必须添加、删除数据，或者可能必须重新排列现有数据。本节的基本模式是消息转换器。端点模式描述消息传递系统客户端如何生成或使用消息。系统管理模式描述了保持复杂的基于消息的系统运行的工具，包括处理参与系统中的错误情况、性能瓶颈和变化。Design patterns are not weakness in languages. They provide design solutions to recurring problems.
Since many things have been evolving over time, I think Enterprise Integration Patterns are going to be popular.
If different enterprise application have to communicate, these patterns provides best solutions.
Integration Stylesdocument different ways applications can be integrated, providing a historical account of integration technologies. All subsequent patterns follow the Messaging style.Channel Patternsdescribe how messages are transported across a Message Channel. These patterns are implemented by most commercial and open source messaging systems.Message Construction Patternsdescribe the intent, form and content of the messages that travel across the messaging system. The base pattern for this section is the Message pattern.Routing Patternsdiscuss how messages are routed from a sender to the correct receiver. Message routing patterns consume a message from one channel and republish it message, usually without modification, to another channel based on a set of conditions. The patterns presented in this section are specializations of the Message Router pattern.Transformation Patternschange the content of a message, for example to accommodate different data formats used by the sending and the receiving system. Data may have to be added, taken away or existing data may have to be rearranged. The base pattern for this section is the Message Translator.Endpoint Patternsdescribe how messaging system clients produce or consume messages.System Management Patternsdescribe the tools to keep a complex message-based system running, including dealing with error conditions, performance bottlenecks and changes in the participating systems.要回答“他们有什么模式？”的问题：
Java 有 Singleton 模式，它是在 Kotlin 中使用 object 关键字 实现
我不知道如果模式是语言的弱点，但对我来说，Kotlin 的优势之一是它使单例的使用变得容易。
To answer the question "What patterns will they have?":
Java haves the Singleton pattern which is implemented in Kotlin with the object keyword
I don't know if patterns are weakness of languages, but for me it's one of Kotlins strengths that it makes the use of Singletons easy.