Using Components and Component Interfaces 
The Web Dynpro Framework enables you to use functions and data from one component in another by using a component in another component. A prerequisite for this is that a usage declaration is created in the "using" component at design time. This itself requires the used component to exist and be recognized by its name. This is not always the case, however. To help you in cases whether the used component cannot be identified, Web Dynpro Framework offers a less rigid technology: Component interface definitions. In this case, you first enter the usage of a separately defined component interface. All components that implement precisely this interface definition can now be used by means of the usage declaration from the main component. The concrete implementation of this method is passed as a parameter at runtime.
Example
If a component wants to embed two components that are not yet known at design time, all components that are able to be embedded must implement a common interface definition. The calling component creates two usages for the interface. At runtime, the implementation is passed as a parameter when the used components or interfaces are created.
A component can implement multiple interfaces.
Interfaces cannot be inherited.
You can implement interfaces in the Application Configuration or by calling them as ULR parameters.
Caution
Interfaces do not implement their own namespaces. We recommend strongly that you use prefixes when you name your interfaces.
Using interfaces in a Web Dynpro component benefits customers by giving them a clean basis for their own further developments. When creating a local development, you can implement a used interface in a separate component and add your own aspects to an application delivered by SAP.
In certain circumstances, you may want a main component to use an individual component more than once. To enable this, you can create multiple usages for the same component. The same applies to the usage of interface definitions.
As long as the number of used components is reasonable and known already at design time, we recommend that you use a usage group instead of a static list of individual usages. Usage groups organize the dynamically programmed use of components or interface definitions.
Note
Before you decide to use a solution that involves dynamic component usages, remember that you also need to program navigation to any components whose use is implemented using usage groups. This makes navigation more complicated and also means that the application is more difficult to maintain.