我们处理接口和实现，就像我们处理内容和样式，所以为什么不同样处理它？

Question

我使用过Spring，我已经研究过Guice，我认为这些都是语言的突兀扩展。我坚信编程语言本身需要适应依赖注入，测试等更具凝聚力的模式，那么为什么不倾向于采用基于样式表的方法呢？通过允许多个“样式”，您可以为不同目的定义对象的配置。也许类和其他优点可以允许您指定比简单的类/方法名称匹配更强大的事务范围。

这对任何人来说都是个好主意吗？另外，您是否认为DI和AOP将作为核心功能集成到未来的语言中，而不是事后的想法？我只是想，看起来像界面 - ＆gt;实现几乎完全对应于数据 ​​- ＆gt;风格。

思想？

Answer 1

这是一个非常古老的想法，首先在20世纪80年代初实施。然后通过术语“配置编程”，“软件集成电路”或“架构描述语言”知道它。 “依赖注入”是企业开发人员最近重新发现这些想法时创造的新词。

例如，查看Conic [1]和Regis / Darwin [2]系统。这些系统用于编写工业控制软件，直接影响了菲利普斯电视机的软件编写方式。 Darwin的一个有趣特性是该语言同时具有文本和图形表示[3]和formal semantics。

Conic和Regis / Darwin比现有的DI框架做得更多，因为它们被用来构建分布式系统：配置语言被编译成一个程序，在一个机器网络上并行部署系统（形式语义定义了这个“精心制作”过程运作）。相比之下，Spring，Guice等只在单个地址空间内配置对象，并且将分布式组件连接到程序员时会遇到更大的困难。

该想法的另一个重新发现是用于传感器网络应用程序的TinyOS操作系统，尽管它没有像组件和配置这样简洁的概念模型。

1. Kramer，J.，Magee，J.，Sloman，M.S。，和Lister，A.，CONIC：An Integrated Approach to Distributed Computer Control Systems，IEE Proceedings。，130，Pt。 E，（1983），1-10。
2. Magee，J.，Dulay，N。和Kramer，J.，Regis：分布式程序的建设性开发环境，分布式系统工程期刊，Vol。 1，No。5.，1994年9月，304-312
3. Kramer，J.，Magee，J.，and Ng，K.，Graphical Configuration Programming，IEEE Computer，22（10），（1989），53-65。

**现在可能“已经”了。