Component Design Patterns Stupid Questions Component Design Patterns Stupid QuestionsNot to sound negative or arrogant (the title is 100% tongue-in-cheek), this is a page dedicated to providing a central place to reference wiki pages that have been created during the course of the ComponentDesignPatterns project that allowed us to ask "stupid questions". They are definitions or thoughts about ideas that we otherwise took for granted until someone asked the question.
Here is a list of things:
Reply: More a particular type... A component is an object that is designed to be used within a ComponentFramework... The interface and behaviour is defined by a class... Component classes are packaged into some unit of deployment such as a DLL.
A set of domain-specific AbstractInteractions must be defined so that components can be developed independently and later integrated to achieve a set of tasks in that domain. An abstract interaction is typically defined as a set of abstract interfaces.
This is what a ComponentFramework provides, along with PrebuiltFunctionality to perform common tasks in its domain...A ComponentFramework is often layered above other component frameworks (LayeredFrameworks).
Stupid question #2: What are some "benefits" and "problems" of components?
Reply:
Benefits: reuse, faster development, higher return on investment.
Problems: One problem, especially in global or large production environments: You need to figure out exactly what your project depends on that's not already a part of the basic operating system build, and make sure you deploy with full understanding of its effect on the infrastructure (you will be using components that others use, and others will be perhaps using yours, so do lots of testing). Things like GroupPackaging and IndividualPackaging.
The GroupPackaging and IndividualPackaging pages have been updated to emphasize the different contexts in which they are used. --NatPryce.
Components tend to be very inflexible. If you attempt to use a component in a manner which differs from what the designer intended, you will run into extended development time (usually trial and error), and buggier software. As most components tend to be poorly documented, if documented at all, use of components rarely provides the benefits claimed by their proponents.
Newer releases of components may deprecate features needed in your application.
Retesting with new releases of components is time consuming. Newer components may also require OS updates or service packs, adding to your maintenance difficulties.
Tracking of small component vendors as they change names, merge, or go out of business is time consuming.
Because the middleware platforms used by some CBD frameworks emphasizes DistributionTransparency?, even to the point of trying to make distribution completely transparent. Unfortunately, distribution issues then drop below the viewpoint of many programmers who use those frameworks.
Distributed computing is hard. But if I don't look at the hardness, perhaps it will cease to be hard. A framework is an excellent way to hide hardness so I don't have to look at it.
Perhaps? Is that really good enough?
This page mirrored in ComponentDesignPatterns as of April 29, 2006