Dissection of an Application Framework - Pluggable Components
(Page 5 of 7 )
To enable hot spots through pluggable components, the application framework must first define the interface for the hot spot. An interface describes a set of methods a class must implement to be considered compatible with the interface. The interface describes what the methods inside the class look like, such as the method names, the number of parameters, and the parameter types, but not how they should be implemented. The following is an example of an interface definition in C#:
public interface ICalculateTax
{
float CalculateStateTax();
float CalculateFedTax();
float Income
{
get;set;
}
}
You can then create application components that support ICalculateTax by creating a concrete class and implementing every method/property defined in the interface, such as the NewYorkBusiness class shown as follows:
public class NewYorkBusiness : ICalculateTax
{
private float income;
public float Income
{
get { return income; }
set { income = value; }
}
public float CalculateStateTax()
{
return income * 0.1F;
}
public float CalculateFedTax()
{
return income * 0.2F;
}
}
Because NewYorkBusiness implements the ICalculateTax interface, it now becomes compatible with or pluggable to any hot spot in the framework that can work with the ICalculateTax interface. With the help of interfaces, application developers can compose the custom behaviors into the underlying framework by loading the pluggable application components in the hot spots of the framework. Figure 2-6 illustrates how the composition approach enables the hot spots in the application framework.
Figure 2-6. A Pluggable application component
In using the composition approach to enable the hot spot, developers will need to create pluggable application components that have matching interfaces with the hot spot in the framework. The developer can then plug the component into the hot spot by binding the application component and the framework component together.
This composition approach for enabling hot spots is based on yet another GOF design pattern called “strategy.” You will learn more about the strategy pattern in Chapter 5.
Now let’s convert the tax example so that the hot spot is enabled through the composition approach. First, we need to modify the BasicBusiness component. Instead of making it an abstract class, this time we will make it a concrete class. The following code snippet shows the new BasicBusiness component:
public class BasicBusiness
{
public void ReportTax (ICalculateTax calculator)
{
float sTax = calculator.CalculateStateTax();
float fTax = calculator.CalculateFedTax();
bool ok = CheckBankBalance(sTax + fTax);
if (!ok)
{
FileBankruptcy();
}
else
{
SendMoneyToGov(sTax + fTax);
}
}
}
The ReportTax method now takes an input parameter of ICalculateTax type. This input parameter will provide the custom tax calculation mechanism, which is also a hot spot in the BasicBusiness framework component. As you can see, by plugging in the custom application component, we effectively “fill up” the hot spot with application-specific business logic/knowledge.
The following example shows how we can plug the application component into the framework from the application code:
ICalculateTax nyBusiness = new NewYorkBusiness(); ICalculateTax caBusiness = new CaliforniaBusiness();
BasicBusiness basic= new BasicBusiness();
basic.ReportTax(nyBusiness);
basic.ReportTax(caBusiness);
In the previous example, each ReportTax call will result in a different outcome, since the framework component is bound to a different ICalculateTax component on each call.
In order for the framework component to load the pluggable object, you can either use the approach described in the previous example or store the application component’s type information inside a configuration file, then load the appropriate component through reflection and plug it right into the framework component dynamically.
Identifying and enabling common spots and hot spots are the central themes of application framework development. Depending on how you enable such spots, you create either a white-box framework, a black-box framework, or a gray-box framework.
White-Box Frameworks A white-box framework is a framework that consists of abstract classes. Adapting a white-box framework requires developers to create concrete classes that inherit the abstract classes in the framework. White-box frameworks take on the inheritance approach to enable their hot spots. Figure 2-7 shows a white-box framework.
Figure 2-7. A white-box framework
A white-box framework is relatively easy to develop. You can start developing the abstract class by looking at some of the similar applications you have developed before, identifying their hot spots, and making them the abstract methods. When developing white-box frameworks, you are making an assumption about the pattern of process flow involved in each framework component through the template method. You often base these assumptions on business-domain expertise and prior business-application development experience. As developers start adapting the white-box framework, they need to program only a small number of “override” methods in the derived class and don’t have to worry about the overall process flow or how the abstract method is used inside the framework. This allows developers to focus solely on the abstract method without worrying about how the methods they are overriding relate to the rest of the framework.
Of course, there is a tradeoff in almost everything. White-box frameworks are very easy to design and develop, but they have their drawbacks. The first drawback is their inflexibility. In a white-box framework, when you determine how the process flow occurs inside a component through the template method you effectively hard-code the process flow and coordination logic in the component. Although developers who adapt the component may change the logic of the component’s hot spot, the overall process flow is nevertheless fixed. This “hard-coded” process flow is reflected as inflexibility when a change in business rules triggers a change in the process flow in the component. Because the process flow and coordination logic are fixed, you would have to update the existing component or write a new one that carries the process flow and coordination logic.
Another drawback of a white-box framework is that it often requires the developer to know many implementation details of the framework component. As the developer is implementing the abstract method in the framework component, he or she often needs to reference the abstract class’s methods and variables in the implementation code. This makes the understanding of internal details of the framework component an important prerequisite for correctly adapting the component.
A black-box framework often takes a composition-style approach to solving some of the challenges of the white box, but it has its own share of drawbacks.
 This chapter is from Developing Application Frameworks in .NET by Xin Chen (Apress, 2004, ISBN: 1590592883). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Black-Box Frameworks >>
More .NET Articles
More By Apress Publishing
