我们对待接口和实现就像对待内容和样式一样，那么为什么不同样处理呢？

Question

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

这对任何人来说都是个好主意吗？另外，您是否认为 DI 和 AOP 将作为核心功能集成到未来的语言中，而不是事后才想到？我只是在想，似乎接口->实现几乎完全对应于数据->样式。

想法？

Answer 1

这是一个非常古老的想法，在 1980 年代初首次实施。然后它被称为“配置编程”、“软件集成电路”或“架构描述语言”。 “依赖注入”是企业开发人员最近重新发现这些想法时创造的新词。

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

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

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

1. Kramer, J.、Magee, J.、Sloman, M.S. 和 Lister, A., CONIC：分布式计算机控制系统的集成方法，IEE Proceedings.，130，Pt。 E，（1983），1-10。
2. Magee, J.、Dulay, N. 和 Kramer, J., Regis：分布式程序的建设性开发环境，分布式系统工程杂志，卷。 1，第 5 期，1994 年 9 月，304-312
3. Kramer, J.、Magee, J. 和 Ng, K.，图形配置编程，IEEE 计算机，22(10)，(1989)，53-65。

** 现在可能“曾经”。