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

Question

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

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

思考？

Answer 1

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

例如,查看Conic [1]和Regis/Darwin [2]系统.这些系统用于编写工业控制软件,直接影响了菲利普斯电视机的软件编写方式.达尔文的一个有趣特征是该语言既有文本和图形表示[3],也有形式语义.

Conic和Regis/Darwin比现有的DI框架做得更多,因为它们被用于构建分布式系统:配置语言被编译成一个程序,该程序在一个机器网络上并行部署系统(形式语义定义了这种"精心制作"的方式)过程运作).相比之下,Spring,Guice等仅在单个地址空间内配置对象,并且将分布式组件连接到程序员时留下了更大的困难.

另一个重新发现的想法是用于传感器网络应用的TinyOS操作系统,尽管它没有那么干净的组件和配置的概念模型.

1. Kramer,J.,Magee,J.,Sloman,MS,和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.

**现在可能"已经"了.