什么是组件驱动开发？
组件驱动开发术语开始得到广泛使用，尤其是。 与控制反转有关。
- 它是什么？
- 它解决什么问题？
- 什么时候合适，什么时候不合适？
Component-Driven Development term is starting to get used widely, esp. in connection with Inversion of Control.
- What is it?
- What problems does it solve?
- When is it appropriate and when not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在您尝试使用 Unity 3D 之前，您永远不会理解什么是真正的组件驱动开发。 它不是 ActiveX 或您以前见过的任何东西，您以前见过的东西有另一种组件含义。
组件驱动开发，关于最近每个人谈论的，意味着，你有两件事：
因此： 组件 - 不是对象。 它是——对象的功能。
因此，在标准的OOP编程中，当您需要使用新功能扩展基础对象时，您必须通过继承基础对象来创建新的派生对象。
在组件驱动开发中，当您需要扩展对象时，您只需创建空对象并用不同的组件填充它，无需任何继承。 在组件驱动开发中，没有类，而是有预制件 - 它是带有预定义组件和子对象的预定义对象。
正如我所说，除非你尝试，否则你永远不会理解。 通过组件驱动开发，您不必总是使用编程，您可以使用图形编辑器来代替，并且它还使您摆脱了典型 OOP 的继承地狱。 组件本身是用通常的编程方式编写的，但更高层次的系统，包括对象，大多只需要在编辑器中使用和组合组件并接收自定义的对象行为。
因此：组件驱动开发为您提供：
我还想补充一点，基于组件（驱动）的编程并不是 OOP 编程的替代品，它是 OOP 或通常编程的基础。 CBP 中仍然使用通常的编程来实现低级组件。
我认为这篇文章对 CBP 也有很好而简短的解释：http: //acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf
You will never understand what is really Component-Driven Development, untill you try to use Unity 3D. It is not ActiveX or anything you ever seen before, what you have seen before has another Component meaning.
Component-Driven development, about every one talking lately, means, you have 2 things:
Thus: Component - is not an Object. It is - Functionality of an Object.
So, in standard OOP programming, when you need to extend Base Object with new Functionality, you have to make new Derived Object by Inheriting Base Object.
In Component-Driven development, when you need extended Object, you just create Empty Object and fills it with different Components, without any Inheritance. In Component-Driven development there is no Classes, there is Prefabs instead - which is predefined Objects with predefined Components, with Children Objects.
As i said you will never understand untill you try. With component-drived development you dont have to always use programming, you may use graphical editors instead, and also it frees you from Inheritance Hell of typical OOP. Components itself programmed with usual programming, but higher level system, including objects, mostly only need to use and combine Components in Editor and receive customized objects behaviour.
Thus: Component-Driven Development gives you:
I also wanna add, that Component-based(driven) programming is not replacement for OOP programming, it is on TOP of OOP or usual programming. Usual programming still used in CBP for low level Component's implementation.
I think this article also have good and short explanation of CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf
如果您有兴趣将组件（或其他可重用资产）组合到应用程序中，您还应该查看 软件产品线方法论。
在软件产品线中，组件（或较低级别的代码元素）之间的依赖关系在这些组件之外进行显式管理。 这通常是使用包含以下规则的功能模型来完成的：
根据您希望建模的依赖关系的复杂性，也可以使用其他更复杂的规则。
有时代替特征建模使用的另一种方法是使用代码生成器来配置要组装到最终应用程序中的不同组件。 还可以将特征建模与代码生成结合起来。
除了代码生成之外，您还可能搜索一些其他术语，例如特定领域建模、模型驱动软件开发、软件系列。
If you're interested in combining components (or other reusable assets) into applications you should also take a look at the software product lines methodology.
In a software product line the dependencies between components (or lower-level code elements) are explicitly managed outside those components. This is typically done using a feature model that contains rules such as
Other more complex rules are possible depending on the complexity of the dependencies you wish to model.
Another approach that is sometimes used instead of feature modelling is to use a code generator to configure the different components that are to be assembled into the finished application. It's also possible to combine feature modelling with code generation.
Aside from Code Generation, some other terms you might search for as domain-specific modelling, model-driven software development, software family.
我将基于组件的软件工程视为一种通过使用可插入组件来开发软件系统的方法； 组件是“仅具有合同指定的接口和显式上下文依赖关系的组合单元”，“可以独立部署并受第三方组合的约束”。 （Clemens Szyperski，“组件软件：超越面向对象编程”）
CBSE 促进代码重用和灵活/适应性强的软件系统的快速组装。
多年来，已有大量研究集中在这个主题上。 旗舰活动（ACM SIGSOFT 基于组件的软件工程研讨会）现已进入第 14 个年头，有不少新趋势正在出现。
另外，如果您想要一个当今业界广泛使用的可重用、可插拔和可扩展组件的好示例，请查看 MS 企业库。
I view Component-Based Software Engineering as an approach to developing software systems through the use of pluggable components; with a component being "a unit of composition with contractually specified interfaces and explicit context dependencies only", which "can be deployed independently and is subject to third-party composition." (Clemens Szyperski, "Component software : beyond object-oriented programming")
CBSE facilitates code reuse and rapid assembly of flexible/adaptable software systems.
There's a substantial research that has been focused on this topic for years. The flagship event (ACM SIGSOFT Symposium on Component Based Software Engineering) is in the 14th year now and there are quite a few new trends emerging.
Also, if you want a good example of reusable, pluggable and extensible components, heavily in use by industry today, take a look at MS Enterprise Library.
基于组件的开发并不是什么新鲜事。 我不知道组件驱动开发，但我假设它是 CBD。 这就是 Unix 的设计方式，一堆可替代的小程序，每个程序都很好地完成一件事。 在桌面领域，Delphi的VCL在使用具有丰富的可重用组件和第三方市场的组件方面取得了无与伦比的成功。 随着一些技术的成熟，我们现在看到 CBD 的复兴。 例如，简单的 Web 应用程序正在发展为 SOA 和 RESTful WS。 所有 Java 人员一直在谈论的都是模块化和 IoC。
您正在寻找的答案可能会在控制反转的原因和内容中找到作者：柯金.
根据 Wikipedia，基于组件的开发是基于组件的软件工程 (CBSE)。
这有点模糊，所以让我们看看更多细节。
因此，根据这个定义，组件可以是任何东西，只要它真正做好一件事并且只做一件事。
所以这听起来越来越像我们认为好的 API 或 SOA 应该是什么样子。
提供的接口由棒棒糖表示，必需接口由附加到 UML 中组件外边缘的开放套接字符号表示。
（来源：wikimedia.org )
可替换性和可重用性是组件之所以成为组件的原因。
那么这和面向对象编程有什么区别呢？
Component-Based Development is nothing really new. I don't know of Component-Driven Development, but I am going to assume it's CBD. It's how Unix is designed, bunch of substitutable small programs each doing one thing very well. In desktop arena, Delphi's VCL has been successful at using components with rich reusable components and third party market like no other. We are now seeing the revival of the CBD as some technologies are maturing. For example simple web apps are evolving to SOA and RESTful WS. All Java guys been talking about is modularity and IoC.
The answer you are looking for likely will be found in Why and what of Inversion of Control by Ke Jin.
According to Wikipedia, Component-Based Development is an alias for Component-based software engineering (CBSE).
This is somewhat vague, so let's look at more details.
So, according to this definition, a component can be anything as long as it does one thing really well and only one thing.
So this is sounding more and more like what we think of good API or SOA should look like.
The provided interfaces are represented by a lollipop and required interfaces are represented by an open socket symbol attached to the outer edge of the component in UML.
(source: wikimedia.org)
Substitutability and reusability is what makes a component a component.
So what's the difference between this and Object-Oriented Programming?
这是我在做了一些研究后的定义。
组件驱动开发是软件开发中的一种方法，其中代码被分割成可重用和可测试的组件，这些组件组合在一起形成应用程序基础用于提供业务功能。 组件的组合和管理通常委托给控制反转容器。
组件本身是一个类，它实现一些服务契约并显式定义履行该契约所需的依赖关系。 实际的实现对组件之外的其他人都是隐藏的。
相关链接：
Here's my definition after doing some research.
Component-Driven Development is an approach in software development in which code is fragmented into reusable and testable components that are combined together to form application foundation for delivering business functionality. The combination and management of components is usually delegated to Inversion of Control Container.
A component itself is a class that implements some service contract and explicitly defines the dependencies that it needs in order to fulfill this contract. Actual implementation is hidden from everybody else outside the component.
Related links:
我不确定这是一个“广泛使用”的术语，但在 VCS（版本控制系统）中，我知道有两种方法来管理构建程序所需的一组文件：
应用架构用于识别这些组件：
这就是 IoC 的用武之地，因为它是任何框架的基础。 它解决的问题是让您更好地识别应用程序的部分：
假设您设计一个 PLR（损益）应用程序，负责计算交易者的损益（头寸）。
您很快就会意识到它不是单个应用程序，而是多个应用程序的组合：
您可以识别计算框架（Ioc），它使您能够插入不同的模块，然后由您的框架在正确的时间调用这些模块。
或者，您可以纯粹识别技术框架（KPI、日志、异常管理），然后您的任何其他< em>功能组件。
在项目管理方面，这还允许您独立开发每个部分，同时通过 VCS 确保全球协调。
I am not sure it is a "widespread" terminology, but in VCS (Version Control System), I know of two ways to manage a set of files needed to build a program:
The applicative architecture is used to identify those components:
That is where IoC comes in, since it is at the base of any framework. The problem it solves is allow you to better identify the part of your application:
Suppose you design a PLR (Profit and Loss) application, in charge to compute the gain and losses (position) of a trader.
You would quickly realize it is not a single application, but a composition of several:
You can then identify a computation framework (Ioc) which would enable you to plug-in your different modules, which then are called at the right time by your framework.
Or you can identify purely technical frameworks (KPI, logs, exception managements) which can then be used by any of your other functional components.
In term of project management, that also allows you to develop each part independently, while assuring a global coordination through the VCS.
我认为你的回答中的定义很好地涵盖了这个问题。 尽管如此，我质疑为什么定义包括组件需要显式定义其依赖项。 组件的一个典型示例是 ActiveX 控件 - 它们是否需要显式定义其依赖项？
复杂性管理。 它试图通过允许您只考虑组件的实现来解决这个问题。 人们应该只需要编写组件，而不应该考虑如何组合或管理它们。 这是由组件外部的某些框架或基础设施完成的，对于组件作者来说并不重要。
不一定适合琐碎或一次性的应用程序。 组件架构中的坏味道是，如果您花时间思考或研究基础架构来管理和组合组件，而不是组件本身。
I think the definition in your answer covers this question well. Although, I question why the definition includes that a component needs to explicitly define its dependencies. A canonical example of a component is an ActiveX control - do they need to explicitly define their dependencies?
Management of complexity. It seeks to address that by allowing you to only ever think about the implementation of the component. One should only need to author components, one should not to have to think about how to combine or manage them. That is done by some framework or infrastructure external to the component, and unimportant to the component author.
Not necessarily appropriate in a trival or throw-away application. The bad smell in a component architecture, is if you are spending time on thinking or working on the infrastructure to manage and combine components, rather than the components themselves.