devise模式真的是语言的弱点吗？
今天的模式应该被视为Java和C ++中的缺陷或缺失的特征 ？
- 子程序是50年代和60年代机器语言的devise模式。
- 面向对象的类是C在70年代的devise模式。
-
Visitors，Abstract Factories，Decorators和Façades是当今Java和C ++的devise模式。
明天的语言会是什么样子？ 他们有什么样的模式？
一些标准化的devise模式 – 适配器，工厂，命令，访问者等等 – 都是近似于被烘焙成其他语言的特征。 closures我的头顶上：
-
C＃中的事件处理程序是观察者模式的烘焙版本。 考虑一下，如果你每次都必须推出你自己的观察者，你将如何在C＃中连接事件。
-
访问者模式是多方法的详细近似， 消息转发或模式匹配的一种非常弱的forms。
-
命令模式包装了一个特定的行为，所以你可以在方法之间传递对象，这或多或less地接近一等function。
-
策略模式允许您dynamic地将行为插入到对象中，以便在任何时候都可以通过交换另一个行为来修改对象。 在函数式编程的世界里，我们称之为函数式组合。
-
抽象工厂模式接受一个参数，并返回一个工厂作为结果。 一般来说，你可以把工厂视为一个函数的基本包装（更具体地说，是一个构造函数的包装）。 所以，你将parameter passing给一个函数，并得到一个函数作为结果，使这个模式非常类似于currying。
-
Decorator模式允许您在运行时将行为附加或移除到对象。 在JavaScript中，您可以添加或删除函数，而无需显式实现装饰器模式，这要感谢“原型”OO模型。
所以，我们有一大堆模仿其他语言固有function的devise模式。 特征羡慕并不一定表明语言的弱点 – 这是你需要反复写下来的样板代码，这表明语言的弱点。
我不会称之为缺陷。
高阶语言处理比低阶语言更高级别的概念。 从构build的angular度来考虑它。
你可以在炼油厂一级build造一座build筑物，铣削木材，冶炼钢铁，然后用这种方法build造一座build筑物。
你可以购买板和钢梁，并build设成一个build筑物。
你可以购买预制的墙壁和桁架，并把它们build设成一个build筑物。
你可以购买一栋build筑，从内部开始。
正在build造一座缺less预制墙体特征的板和桁架，或者在某种程度上有缺陷？
你在软件devise中做三次或三次以上的每件事都形成了一个模式。
每一次重复。 每一次重复。 每一次重复。
有些人得到了很酷的名字。 这些成为devise模式。 有意识的重复。
有些只是“最佳实践”或“这对我有效”。 这些都是没有明确的devise模式。
有些只是“你通常做的事情”。 这些都是devise模式，没有任何意识到你在重复自己。
devise模式与语言薄弱或不完整无关 。 他们都有好的想法，有意识地重用。
今天的devise模式不是通往明天语言的王道。 语言范例并没有通过一系列“对以前的语言的错误修正”。 如果是这样，我们就不会创buildVisual Basic。
与简单的编程语言function集相比，devise模式是一个更大更广的智能工具。
不，他们不缺less语言的特征或缺陷。 但是，语言应该提供一种方法来编写有用的模式的代码，而不是困难的。 这就是语言所提供的function可能是一个恩赐或阻碍。
我认为伊万提出了一个迷人的观点。 以他的“子程序”为例。 在早期的编程语言中，将parameter passing给子例程并返回结果的想法是你必须明确编码的。 在现代语言中，它是内置的。或者再举一个例子：如果/ then / else被构build到大多数（如果不是所有的）现代语言中。 但回到我的汇编时代，我不得不编写代码来实现这一点。 当然不是很多，但是，实际上，你必须写下跳转或者跳转语句来绕过else块。 事实上，你必须自己写这些东西，这意味着不同的程序员会以不同的方式去做，而且在这个程序中有着无尽的诱惑和聪明，并且做得有点不同，以使它更有效率或者获得更多的好处应该有优势。
想到的最近的例子是迭代器。 你必须用C ++和早期版本的Java手写它们，但是它们是内置于Java 5中的。这可以说是句法糖，你也可以简单地创build迭代器函数。 我个人认为这是一个很好的function。 它是否从根本上提高了我的生产力？ 没有。
有没有什么我们一直在做的事情，应该在逻辑上被纳入语言来标准化和简化呢？ 一个迷人的问题。 我不认为任何人会认真地声称，即使他们最喜欢的语言是完美的，绝对没有改善是可能的。 但下一个语言的方向是什么？
当然，一些已经join语言的function是无用的额外行李。 在我看来，Java枚举的办法不仅仅是必要的，而且还没有很好的理由增加了一堆行李。 我相信别人会不同意，并说他们觉得他们非常有用。
我没有一个结论。 我只是同意这是一个有趣的问题。
我认为一些devise模式确实代表了语言的弱点，新的语言将现有的模式融入了一等公民。 以其他语言（dependency injection，不变性等）的现有devise模式并将它们合并为一级语言级别特性的新语言的一个示例是来自Google的NOOP 。
我想知道在语言变得太“大”之前，你可以塞进一种语言。
我喜欢和我一起工作的语言小到可以一下子把我的脑袋都抱在怀里。 DI等模式与结构性问题有关; 应该是语言的一部分吗？
开发者真的需要多less手语？
在代码合同（要求，确保）的情况下，这是很好的，当它是语言的头等部分，但它不是必需的。 它仍然可以成为图书馆的一部分。
我读过的地方就是“你拥有的模式越多，语言越弱”，我觉得这个定义非常好。
原因是国际海事组织清楚：如果你看到一个重复的模式（或者你必须使用它），这意味着它是一种复制粘贴在逻辑层面上。 当然，它不像复制粘贴语句那样糟糕，但它仍然是冗余的。 我仍然一遍又一遍地重复着自己。
语言的expression越多，你就越应该能够捕获这些冗余，并将其重新转换为重复使用而不是重新实现，而重用将更易于在源代码中阅读和理解。
每当你发现自己再次做同样的事情（包括例如“好的，让我们在这里实现一个抽象工厂”），这意味着这是本来应该在更高层次expression的东西。
当然，有时你可以尝试捕捉某些事物的本质，但重用可能比重新实现更难读（比如我正在考虑<algorithm>中C ++“高级”内容的某些部分）。 这是国际海事组织一个明确的表示，语言不够expression。
有利于语言使用某些模式的框架确实存在，所以它们更多的是一种select而不是必须的。 对于某个项目，有些模式可能根本不需要，因此将其作为主要的语言特征，只会加以限制，而不能促进生产性工作。
每种语言都是一组任意devise模式，其语法如同所选模式的符号。 对于未被select的模式，你必须在语法的约束之内插手来expression它们。 大多数语言不允许其语法改变太多来吸收更高层次的模式。
一种可以无限制地使用的语言将是没有严格语法的语言。 （或以另一种方式，允许无缝地同化任何高级模式）。 看到元语言抽象
我想到的是scheme/口齿不清。
devise模式并不是语言中的弱点。 他们为重复出现的问题提供devisescheme。
由于许多事情随着时间的推移而不断发展，我认为企业集成模式将会stream行起来。
如果不同的企业应用程序需要交stream，这些模式提供了最好的解
-
Integration Styleslogging应用程序Integration Styles不同方式，提供集成技术的历史logging。 所有后续模式遵循消息传递风格。 -
Channel Patterns描述消息如何通过消息通道传输。 这些模式是由大多数商业和开源消息系统实现的。 -
Message Construction Patterns描述了消息传递系统中消息的意图，forms和内容。 这部分的基本模式是消息模式。 -
Routing Patterns讨论如何将消息从发送方路由到正确的接收方。 消息路由模式消耗来自一个通道的消息，并且通常根据一组条件将消息重新发布到另一个通道，而无需进行修改。 本节介绍的模式是消息路由器模式的特化。 -
Transformation Patterns改变消息的内容，例如以适应发送和接收系统使用的不同数据格式。 数据可能不得不被添加，带走或者现有的数据可能需要重新排列。 这部分的基本模式是消息转换器。 -
Endpoint Patterns描述了消息传递系统客户端如何产生或使用消息。 -
System Management Patterns描述了保持复杂的基于消息的系统运行的工具，包括处理错误条件，性能瓶颈和参与系统中的变化。
