什么是组件驱动开发？

Question

组件驱动开发术语开始被广泛使用，尤其是与控制反转有关。

1. 它是什么？
2. 它解决了什么问题？
3. 什么时候适当，什么时候不适合？

Answer 1

它是什么？

我认为你答案中的定义很好地涵盖了这个问题。虽然，我质疑为什么定义包含组件需要明确定义其依赖项。组件的规范示例是ActiveX控件 - 他们是否需要显式定义其依赖项？

它解决了什么问题？

管理复杂性。它试图通过允许您只考虑组件的实现来解决这个问题。人们应该只需要创作组件，不应该考虑如何组合或管理它们。这是由组件外部的某些框架或基础结构完成的，对组件作者来说并不重要。

什么时候适当，什么时候不适合？

在trival或throw-away应用程序中不一定合适。组件体系结构中的难闻气味是，如果您花时间思考或使用基础结构来管理和组合组件，而不是组件本身。

Answer 2

我不确定它是一个“广泛”的术语，但在VCS（版本控制系统）中，我知道有两种方法来管理构建程序所需的一组文件：

• system-based approach，其中所有集合具有共同的生命周期，必须标记为全部
• 基于组件的方法，其中单个文件集具有其自己的生命周期，并且元标签引用组件的所有标签，以通过这些组件之间的组合和依赖性来指定所有系统。

applicative architecture用于识别这些组件：

• 功能域和应用程序
• 第三方图书馆
• 构架

这就是IoC的用武之地，因为它是任何框架的基础。它解决的问题是让您更好地识别应用程序的一部分： 假设您设计了一个PLR（损益）应用程序，负责计算交易者的收益和损失（头寸）。 您很快就会意识到它不是一个单独的应用程序，而是由几个组成：

• GUI
• 发射台
• 调度程序（在几个服务器上调度计算，因为没有足够的内存来计算所有！）
• 等等

然后，您可以确定一个计算框架（Ioc），它可以使您插入不同的模块，然后由框架在适当的时间调用。

或者您可以识别纯粹的technical frameworks（KPI，日志，异常管理），然后您可以使用任何其他功能组件。

在项目管理方面，这也允许您独立开发每个部分，同时确保通过VCS进行全球协调。

Answer 3

基于组件的开发并不是什么新鲜事。我不知道组件驱动开发，但我会假设它是CBD。这就是Unix的设计方式，一堆可替代的小程序，每个程序都做得很好。在桌面领域，Delphi的VCL成功地使用了具有丰富的可重用组件和第三方市场的组件。随着一些技术日趋成熟，我们现在看到了CBD的复兴。例如，简单的Web应用程序正在发展为SOA和RESTful WS。所有Java人员都在谈论的是模块化和IoC。

您正在寻找的答案可能会在Kejin的Why and what of Inversion of Control中找到。

此外，这些经典的OO编程语言的必然性往往会错过树的森林（高级架构/结构）（低级逻辑控制程序代码）。接管现有应用程序的开发和维护工程师必须依赖其过时的设计/体系结构文档和低级代码注释/模式。

基于组件的开发（CBD）范例通过将管道逻辑转换为基于用户/开发人员提供声明性描述来操纵组件和设置应用程序的框架来解决上述两个问题。与常见的混淆相反，这种声明性描述并不意味着应用程序设置脚本。相反，它们的基本意图是明确表达应用程序体系结构/结构，而不强制其命令性管道程序（即描述什么而不是如何）。 CBD范例的目标是通过这些框架支持有效且灵活的应用程序组合，并使应用程序开发人员专注于业务逻辑和域问题，而不涉及低级管道复杂性。

结合声明性应用程序描述和IoC技术的CBD框架称为IoC框架。与其前身相反，IoC框架是非侵入式的，并使用依赖/配置注入/设置方案。

根据维基百科，基于组件的开发是Component-based software engineering (CBSE)的别名。

[它]是软件工程的一个分支，其优先级是关于整个给定软件系统中可用的广泛功能的关注点的分离。

这有点模糊，让我们来看看更多细节。

单个组件是封装一组相关功能（或数据）的软件包或模块。

所有系统进程都放在单独的组件中，以便每个组件内的所有数据和函数在语义上相关（就像类的内容一样）。由于这个原理，人们常说组件是模块化和内聚的。

因此，根据这个定义，组件可以是任何东西，只要它做的一件事情真的很好而且只有一件事。

关于系统范围的协调，组件通过接口相互通信。 [...]这个原则导致被称为封装的组件。

所以这听起来越来越像我们认为好的API或SOA应该是什么样子。

提供的接口由棒棒糖表示，并且所需的接口由以UML连接到组件外边缘的开放套接字符号表示。

（来源：wikimedia.org）

组件的另一个重要属性是它们是可替代的，因此如果后续组件满足初始组件的要求（通过接口表示），则组件可以被另一个组件（在设计时或运行时）替换。

可重用性是高质量软件组件的重要特征。应该设计和实现软件组件，以便可以在许多不同的程序中重用它。

可替代性和可重用性是使组件成为组件的原因。那么这与面向对象编程有什么区别？

面向对象编程（OOP）中的思想是软件应该根据它所代表的实际或想象对象的心理模型来编写。 [...]

相比之下，基于组件的软件工程没有做出这样的假设，而是声明应该通过将预制组件粘合在一起来开发软件，就像在电子或机械领域一样。

Answer 4

这是我做一些研究后的定义。

组件驱动开发是一种软件开发方法，其中将代码分段为可重用且可测试的组件，这些组件组合在一起以形成用于提供业务功能的应用程序基础。组件的组合和管理通常委托给Inversion of Control Container。

组件本身是一个实现某个服务契约的类，并明确定义它为完成此契约所需的依赖项。实际的实现对组件外的所有其他人都是隐藏的。

相关链接：

• Component-Driven Development and IoC Container

Answer 5

我将基于组件的软件工程视为通过使用可插拔组件开发软件系统的方法;组件是“具有合同指定的接口和仅显式上下文依赖关系的组合单元”，“可以独立部署，并受第三方组合的约束”。 （Clemens Szyperski，“Component software : beyond object-oriented programming”）

CBSE有助于代码重用和灵活/适应性软件系统的快速组装。

多年来一直关注这一主题的实质性研究。旗舰活动（ACM SIGSOFT Symposium on Component Based Software Engineering）现已进入第14个年头，并且出现了不少新趋势。

此外，如果您想要一个可重用，可插拔和可扩展组件的良好示例，这些组件已被业界广泛使用，请查看MS Enterprise Library。

Answer 6

如果您有兴趣将组件（或其他可重用资产）组合到应用程序中，您还应该查看software product lines方法。

在软件产品线中，组件（或更低级代码元素）之间的依赖关系在这些组件之外显式管理。这通常使用包含诸如的规则的特征模型来完成

• 这两个组件不能一起使用（互斥）
• 如果使用此组件，则必须使用此其他组件或（相互依赖）
• 可以使用某些指定组件的任意组合（可选性）

其他更复杂的规则是可能的，具体取决于您希望建模的依赖项的复杂性。

有时使用的另一种方法是使用代码生成器来配置要组装到完成的应用程序中的不同组件。也可以将特征建模与代码生成相结合。

除了代码生成，您可以搜索一些其他术语作为特定于域的建模，模型驱动的软件开发，软件系列。

Answer 7

您永远不会理解什么是真正的组件驱动开发，直到您尝试使用Unity 3D。它不是ActiveX或您以前见过的任何东西，您之前看到的具有另一个组件含义。

组件驱动的开发，关于每个人最近的谈话，意味着，你有两件事：

1. 对象 - 就像OOP编程或现实世界对象中的对象一样。
2. 对象的组件 - 它类似于Object的功能或其中一个功能。

因此：组件 - 不是对象。它是 - 对象的功能。

因此，在标准OOP编程中，当您需要使用新功能扩展Base对象时，必须通过继承基础对象来创建新的派生对象。

在组件驱动的开发中，当您需要扩展的Object时，您只需创建空对象并使用不同的组件填充它，而不需要任何继承。在组件驱动的开发中没有类，而是有预制件 - 这是具有预定义组件的预定义对象，带有子对象。

正如我所说，你永远不会理解，直到你尝试。使用组件驱动的开发，您不必总是使用编程，您可以使用图形编辑器，而且它还可以使您从典型OOP的继承地狱中解脱出来。组件本身用通常的编程编程，但更高级别的系统，包括对象，大多只需要在编辑器中使用和组合组件并接收自定义对象的行为。

因此：组件驱动开发为您提供：

1. 通过仅使用编辑器无需编程即可创建程序逻辑的强大功能。
2. 从OOP继承地狱中释放你的思绪。使开发更简单，更快速。
3. 使您的程序高度可定制和可扩展，甚至无需触摸代码。减少错误和错误。
4. 只需重新编程特定组件，即可轻松维护程序代码，而不会影响休息系统。
5. 等等...

我还想补充一点，基于组件（驱动）的编程不是OOP编程的替代品，它是OOP或通常的编程。通常的编程仍然在CBP中用于低级组件的实现。我认为这篇文章也对CBP有很好的简短解释：http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf