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?
Component-Driven Development term is starting to get used widely, esp. in connection with Inversion of Control.
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:
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
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.
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.
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.
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.
alt text http://upload.wikimedia.org/wikipedia/en/2/25/Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif
Substitutability and reusability is what makes a component a component. So what's the difference between this and Object-Oriented Programming?