今天的模式应该被视为Java和C ++中的缺陷还是缺失的功能?
- 子例程是50年代和60年代机器语言的设计模式。
- 面向对象类是70年代C语言的设计模式。
访问者、抽象工厂、装饰器和外观是今天Java和C ++的设计模式。
明天的语言会是什么样子?它们将有哪些模式?
今天的模式应该被视为Java和C ++中的缺陷还是缺失的功能?
访问者、抽象工厂、装饰器和外观是今天Java和C ++的设计模式。
明天的语言会是什么样子?它们将有哪些模式?
所以,我们有一堆设计模式来模拟其他语言固有的特性。特征嫉妒并不一定表明语言的弱点——需要一遍又一遍地编写样板代码才表明语言的弱点。
我不会称它们为缺陷。
高阶语言处理的概念比低阶语言更高级。可以用建筑术语来解释。
您可以在炼油厂水平上建造建筑物,制材、冶钢,并以此方式组装建筑物。
您可以购买木板和钢梁,并将其构建成建筑物。
您可以购买预制墙板和桁架,并将其构建成建筑物。
您可以购买一个建筑物,并直接从内部开始。
使用木板和钢梁构建建筑物是否缺少预制墙板特性或存在缺陷?
在软件设计中,每个你做三次或更多次的事情都会形成一种模式。
每次重复。每次重复。每次重复。
有些模式被赋予了酷炫的名字,它们成为设计模式。这是有意识的重复。
有些只是“最佳实践”或“这对我有用过”,这些是没有清晰性的设计模式。
有些只是“通常要做的事情”,这些是没有任何自觉认识到自己正在重复的设计模式。
设计模式与语言弱点或不完整无关。它们与好的想法有关,是有意识地重复利用。
今天的设计模式并不是未来语言的王路。语言范式不是通过“修补先前语言的漏洞”这样的方式推进的。如果是这样的话,我们永远不会创建Visual Basic。
而且设计模式是一种比简单的编程语言特性更广泛、更大的智力工具。
<algorithm>
)。这在我看来是语言表达能力不够的明显标志。我认为有些设计模式确实代表了语言上的弱点,而新语言则将现有模式纳入一等公民。一个新语言采用其他语言已有的设计模式(如依赖注入、不可变性等)并将它们作为一流语言级别的特性整合进去的例子是 Google 的 NOOP。
我在想一门语言能塞多少东西进去才不会变得太“庞大”。
我喜欢的编程语言足够小,可以一次性全部记住。DI等结构性问题是否应该成为语言的一部分?
开发人员实际上需要多少语言辅助呢?
对于代码合同(requires、ensures),如果它是语言的重要组成部分那当然很好,但并非必须如此。这仍然可以作为库的一部分。
每种语言都是一组任意的设计模式,其语法作为所选模式的符号表示。对于未选择的模式,您必须在语法的限制内进行干预以表达它们。 大多数语言不允许其语法过多地改变以同化更高级别的模式。
一个可以无限制地做到这一点的语言将是没有严格语法的语言(或者换句话说,允许无缝同化任何高级别模式的语言)。 请参见元语言抽象。
我想到的是Scheme/Lisp。
设计模式并不是语言的弱点,它们提供了针对重复问题的设计解决方案。
随着时间的推移,许多事物都在不断发展,我认为企业集成模式将会变得流行。
如果不同的企业应用程序需要进行通信,这些模式提供了最佳解决方案。
集成风格
文档介绍了应用程序集成的不同方式,提供了集成技术的历史记录。所有后续的模式都遵循消息传递风格。通道模式
描述了消息如何通过消息通道进行传输。这些模式由大多数商业和开源消息系统实现。消息构建模式
描述了跨消息系统传输的消息的意图、形式和内容。本节的基本模式是消息模式。路由模式
讨论了如何将消息从发送者路由到正确的接收者。消息路由模式从一个通道消耗一条消息,并根据一组条件将其重新发布到另一个通道,通常不进行修改。本节中介绍的模式是消息路由器模式的特化。转换模式
更改消息的内容,例如以适应发送和接收系统使用的不同数据格式。可能需要添加、删除数据或重新排列现有数据。本节的基本模式是消息翻译器。端点模式
描述了消息系统客户端如何生成或消费消息。系统管理模式
描述了保持复杂的基于消息的系统运行所需的工具,包括处理错误条件、性能瓶颈和参与系统的更改。