组件驱动开发术语开始得到广泛应用,尤其是与控制反转有关。
答案 0 :(得分:13)
这是什么?
我认为你答案中的定义很好地涵盖了这个问题。虽然,我质疑为什么定义包含组件需要明确定义其依赖项。组件的规范示例是ActiveX控件 - 他们是否需要明确定义其依赖项?
它解决了什么问题?
管理复杂性。它试图通过允许您只考虑组件的实现来解决这个问题。一个人应该只需要创作组件,一个人不就必须考虑如何组合或管理它们。这是由组件外部的一些框架或基础结构完成的,对组件作者来说并不重要。
何时适当,何时不适合?
在trival或throw-away应用程序中不一定合适。组件体系结构中的难闻气味是,如果您花时间思考或使用基础结构来管理和组合组件,而不是组件本身。
答案 1 :(得分:10)
我不确定它是一个“广泛”的术语,但在VCS(版本控制系统)中,我知道有两种方法来管理构建程序所需的一组文件:
applicative architecture用于识别这些组件:
这就是IoC的用武之地,因为它是任何框架的基础。它解决的问题是让您更好地识别应用程序的一部分:
假设您设计了一个PLR(损益)应用程序,负责计算交易者的收益和损失(头寸)。
您很快就会意识到它不是一个单一的应用程序,而是几个组合:
然后,您可以识别一个计算框架(Ioc),它可以让您插入不同的模块,然后由框架在适当的时候调用。
或者您可以完全识别technical frameworks(KPI,日志,异常管理),然后您可以使用任何其他功能组件。
在项目管理方面,这也允许您独立开发每个部分,同时确保通过VCS进行全球协调。
答案 2 :(得分:8)
基于组件的开发并不是什么新鲜事。我不知道组件驱动开发,但我会假设它是CBD。这就是Unix的设计方式,一堆可替代的小程序,每个程序都做得很好。在桌面领域,Delphi的VCL成功地使用了具有丰富的可重用组件和第三方市场的组件。随着一些技术日趋成熟,我们现在看到了CBD的复兴。例如,简单的Web应用程序正在发展为SOA和RESTful WS。所有Java人员都在讨论模块化和IoC。
您正在寻找的答案可能会在Ke Jin的Why and what of Inversion of Control中找到。
此外,势在必行 这些经典的OO编程语言 往往错过森林(高层次 建筑/结构) 树(低级逻辑控制 程序代码)。发展与发展 维修工程师接管 现有的申请必须依赖 它的过时设计/架构 文档和低级代码 评论/图案。
基于组件的开发(CBD) 范式解决了上述两个问题 通过将管道逻辑转换为 操纵组件的框架 并基于。设置应用程序 用户/开发人员提供声明 说明。与常见的相反 混乱,这种陈述 描述并不意味着 应用程序设置脚本相反, 他们的根本目的是 明确表达申请 没有的架构/结构 强制他们必要的管道 程序(即描述什么 而不是如何)。 CBD的目标 范式是支持有效和 灵活的应用程序组合 这些框架和拥有 应用开发人员专注于 业务逻辑和域问题 没有涉及低级管道 复杂性。
CBD框架结合了 声明性应用程序描述 并提到了IoC技术 作为IoC框架。与他们相反 前辈,IoC框架是 非侵入性并使用 依赖/配置注入/设置方案。
根据维基百科,基于组件的开发是Component-based software engineering (CBSE)的别名。
[它]是软件的一个分支 工程,其优先级是 关注点分离 广泛的功能 在给定的软件中可用 系统
这有点模糊,所以让我们看看更多细节。
单个组件是一种软件 包,或模块,那 封装了一组相关的 功能(或数据)。
所有系统进程都放入 单独的组件,以便所有的 每个内部的数据和功能 组件在语义上是相关的 (就像内容一样 类)。由于这个原则, 通常说组件是 模块化和内聚。
所以,根据这个定义,一个组件可以是任何东西,只要它做的一件事情真的很好而且只有一件事。
关于全系统 协调,组件沟通 通过接口相互之间。 [...] 该原理产生称为封装的组件。
所以这听起来越来越像我们认为好的API或SOA应该是这样的。
提供的接口由棒棒糖表示,必需的接口由连接到UML组件外边缘的开放套接字符号表示。
(来源:wikimedia.org)
另一个重要的属性 组件就是它们 可替代,这样一个组件 可以被另一个替换(at 设计时间或运行时间),如果 初始组件的要求 (通过接口表示)得到满足 由后继组成部分。
可重用性很重要 高品质的特点 软件组件。一个软件 组件应该设计和 实施,以便可以重复使用 在许多不同的计划中。
可替代性和可重用性是使组件成为组件的原因。 那么这与面向对象编程之间的区别是什么?
面向对象的想法 编程(OOP)就是那个软件 应该写一个 心理模型的实际或想象 它代表的对象。 [...]
基于组件的软件工程, 相比之下,没有这样的 假设,而是说明 软件应该通过粘合来开发 预制组件在一起很多 就像在电子领域或 力学。
答案 3 :(得分:5)
这是我做一些研究后的定义。
组件驱动开发是一种软件开发方法,其中将代码分段为可重用且可测试的组件,这些组件组合在一起以形成用于提供业务功能的应用程序基础。组件的组合和管理通常委托给Inversion of Control Container。
组件本身是一个实现某种服务契约的类,并明确定义了履行此契约所需的依赖关系。实际的实现对组件外的所有其他人都是隐藏的。
相关链接:
答案 4 :(得分:5)
我将基于组件的软件工程视为通过使用可插拔组件开发软件系统的方法;组件“具有合同指定的接口和明确的上下文依赖关系的组合单元”,“可以独立部署,并受第三方组合的约束。” (Clemens Szyperski,“Component software : beyond object-oriented programming”)
CBSE促进了代码重用和灵活/适应性软件系统的快速组装。
多年来一直关注这一主题的实质性研究。旗舰活动(ACM SIGSOFT Symposium on Component Based Software Engineering)现已进入第14个年头,并且出现了不少新趋势。
此外,如果您想要一个可重用,可插拔和可扩展组件的良好示例,这些组件已被业界广泛使用,请查看MS Enterprise Library。
答案 5 :(得分:1)
如果您有兴趣将组件(或其他可重用资产)组合到应用程序中,您还应该查看software product lines方法。
在软件产品线中,组件(或更低级代码元素)之间的依赖关系在这些组件之外显式管理。这通常使用包含
等规则的特征模型来完成其他更复杂的规则是可能的,具体取决于您希望建模的依赖关系的复杂性。
有时使用的另一种方法是使用代码生成器来配置要组装到完成的应用程序中的不同组件。也可以将特征建模与代码生成相结合。
除了代码生成之外,您可以搜索其他一些术语作为特定于域的建模,模型驱动的软件开发,软件系列。
答案 6 :(得分:-3)
你永远不会明白什么是真正的组件驱动开发,直到你尝试使用Unity 3D。它不是ActiveX或您以前见过的任何东西,您之前看到的具有另一个组件含义。
组件驱动的开发,关于每个人最近的谈话,意味着,你有两件事:
因此:组件 - 不是对象。它是 - 对象的功能。
因此,在标准OOP编程中,当您需要使用新功能扩展Base对象时,您必须通过继承基础对象来创建新的派生对象。
在组件驱动的开发中,当您需要扩展的Object时,您只需创建空对象并使用不同的组件填充它,而不需要任何继承。在组件驱动开发中没有类,而是有预制件 - 这是具有预定义组件的预定义对象,带有子对象。
正如我所说,你永远不会理解,直到你尝试。使用组件驱动的开发,您不必总是使用编程,您可以使用图形编辑器,而且它还可以使您从典型OOP的继承地狱中解脱出来。组件本身使用通常的编程编程,但更高级别的系统,包括对象,大多只需要在编辑器中使用和组合组件并接收自定义对象的行为。
因此:组件驱动开发为您提供:
我还想补充一点,基于组件(驱动)的编程不是OOP编程的替代品,它是在OOP或通常的编程上。通常的编程仍然在CBP中用于低级组件的实现。 我认为这篇文章也对CBP进行了简短的解释:http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf