In component-base system, we always try to decouple components from each other. Sometime, decoupling process becomes a little bit expensive. In this article, I will talk about a simple approach that can be used for decoupling components, service and extension point pattern.
Why OOP inheritance should not be used?
Service and extension point pattern is similar to general OOP inheritance, but unlike OOP inheritance, it doesn't tight the components with each other. You usually use this pattern when you have a service-provider scenario. For example, suppose component “A” and “B” are in a small HR application called HRTest, component "A" is a module that displays employee information, and component "B" manages data source providers for the application. Data providers can come from different resources like database, web services, or even normal files. As you can conclude, "A" requires at least one provider in order to display employee information to the end user, and B provides the implementation for A's requirements. Using normal inheritance doesn't give a flexible solution because providers may only be exist at runtime, also more than one components can provide the "A" service interface. For instance, "B" and "C". In addition, for some reasons, "C" may be removed at a certain execution point.
As the preceding example shown, "A" is tightly dependent on "B" and "C." Because, when a new provider such as "D" is added or an old one is removed, "A" should be adjusted.
In such above scenario, service and extension pattern can be used to solve this issue in the flexible manner.
Service and Extension Pattern:
Service and Extension Pattern is commonly used approach in RCP platforms like NetBeans and Eclipse for sharing objects and providing implementation for extension points. Extension point (sometimes is called Service Interface) is a simple interface that a component can define in order to be implemented by other component, which is called Implementation provider or simply Provider. An extension point can have more than one provider at runtime and both providers and service modules should not know each other. To clear the misconception between them, the figure below shows a general structure of the pattern
As the figure demonstrated, Component “A” defines an extension point which “B”, “C” and “D” implement at runtime. Note, because extension point is used by all modules, it should be shared. Therefore, it is highly recommended to encapsulate it in a separate component creating a new abstract layer between them.
What is next?
In the next post, we will implement this pattern using NetBeans Lookup API.
Thanks for your reading.
Why OOP inheritance should not be used?
Service and extension point pattern is similar to general OOP inheritance, but unlike OOP inheritance, it doesn't tight the components with each other. You usually use this pattern when you have a service-provider scenario. For example, suppose component “A” and “B” are in a small HR application called HRTest, component "A" is a module that displays employee information, and component "B" manages data source providers for the application. Data providers can come from different resources like database, web services, or even normal files. As you can conclude, "A" requires at least one provider in order to display employee information to the end user, and B provides the implementation for A's requirements. Using normal inheritance doesn't give a flexible solution because providers may only be exist at runtime, also more than one components can provide the "A" service interface. For instance, "B" and "C". In addition, for some reasons, "C" may be removed at a certain execution point.
Class A{
.
.
.
public void getData(number empID){
ServiceProvider[] service = getService();
}
public ServiceProvider[] getServices(){
getProviderB(); // Get B data provider
getProviderC(); //Get C data provider
.
.
.
}
}
As the preceding example shown, "A" is tightly dependent on "B" and "C." Because, when a new provider such as "D" is added or an old one is removed, "A" should be adjusted.
In such above scenario, service and extension pattern can be used to solve this issue in the flexible manner.
Service and Extension Pattern:
Service and Extension Pattern is commonly used approach in RCP platforms like NetBeans and Eclipse for sharing objects and providing implementation for extension points. Extension point (sometimes is called Service Interface) is a simple interface that a component can define in order to be implemented by other component, which is called Implementation provider or simply Provider. An extension point can have more than one provider at runtime and both providers and service modules should not know each other. To clear the misconception between them, the figure below shows a general structure of the pattern
As the figure demonstrated, Component “A” defines an extension point which “B”, “C” and “D” implement at runtime. Note, because extension point is used by all modules, it should be shared. Therefore, it is highly recommended to encapsulate it in a separate component creating a new abstract layer between them.
What is next?
In the next post, we will implement this pattern using NetBeans Lookup API.
Thanks for your reading.
0 comments:
Post a Comment