The CF tightly couples many Objects to build each Custom-AC as shown in the Fig below. The arrows shows the dependencies between the Objects. Please remember, one may need to write several dozens lines of code to initialize and customize each reusable GUI Class such as Chart or graph (for example, to input not only Data but also Style-data such as fonts and colors). So each arrow of dependency may represent dozens of function calls. The CF may get necessary data from other sources such as configuration files to customize the component (e.g. style, national language strings).
Furthermore, the data-pieces obtained from EJB or DB-Objects cannot be readily input to GUI Components, since often need to apply application-logic such as business rules/policies, user-preferences, algorithms or irritate over large data-sets to calculate summaries such as medians/average etc. Don't you agree all this code is essential, which force the developers to tightly-couple the Objects and Logics?
Application Components & Component Factory framework
The web-applications are mainly consists of many screens or web pages; which deliver information. Also may contain form-elements (e.g. check-boxes, radio-buttons or Text-input boxes) for end-user to enter information or send requests. Each web page may consist of many Application Components (or components on the web page). The Application Component or AC is a component (or presentation section on the web page) such as ‘weather-info’ or ‘stock-quote’ as shown in the figure#1 and figure#3.
While the types of ACs vary from application to application and are unique to each application, the process is same. In most web pages we can identify one or more such ACs. For example, CRM (Customer relationship management) application may present customer complaints, satisfaction or response time as charts, graphs and tables etc.; and HR (human resources) application may present organizational maps as hierarchical-trees and employee information/status/performance in a popup for each employee etc. Likewise, Air traffic control systems may contain Flights and Games may contain animated characters such as Race-cars.
Likewise, Fig#3, the CF is nothing but a Java-class, which takes a ticker-symbol of a company as input and creates the HTML-table/SVG-charts code for the stock-quote AC. As shown in the Fig#2, the CF may use one or more reusable GUI-Classes for the charts to generate the code for the AC.
ComponentFactory Weather = new CF_Local_Weather(94089); //Set ZIP-Code
Weather.CGM ( User_Info, Out); // Write the 'Code-block' to present the Component
ComponentFactory Quote = new CF_Stock_Quote( "SUNW"); //Set Ticker Symbol
Quote.CGM ( User_Info, Out); //Write the 'Code-block' to present the Component
The ‘Java Classes’/CF created this way can be instantiated in any JSP/Servlet by just writing one or two lines of code. Hence, the components can be quickly interchangeable, by just replacing these two-lines. Also, if they are implemented as Portlets, they can be accessed from remote web-servers not only to get the information but also as well-packaged 'code-block' for the AC. These Classes can be seen as ‘component-factory’ for weather AC and ‘component-factory’ for stock-quote respectively, because they manufacture ‘ACs’ at real-time as per client/browser requirement and/or profile. Any application, which needs weather information, can request the Java-class to custom create browser/user-profile specific AC at real-time for the city (or zip code) passed to it.
These Java-classes (or CF) are highly independent and any modification to them would not require any updates in the code that uses them to build sub-ACs. Hence, the Java-class can be independently refined or redesigned to meet evolving needs. Also such classes can be made intelligent and adaptable. For example, ‘stock-quote’ may access the user profile and customize the AC for each user by choosing appropriate charts as per his preferences. Hence, the CF not only can produce ‘AC’ but also may customize it as per user preferences.
Pseudo-code listing#1
1.
Likewise, it is also possible to create larger-CF for comprehensive stock information AC. The larger-CF uses many CFs to build charts (or sub-ACs). For example, the following pseudo CGM() code shows, how larger CF may use other CFs to include sub-ACs.
This following pseudo method code listing shows, how one may use other Component factories or GUI-classes to build subcomponents. This larger CF could take a Ticker symbol to build a component as shown in the above figure. The Objects of this CF-Class can be used again, for example, to build subcomponents for a larger portfolio Tab-Class. The tab-component shows the company names as Tabs to select or to switch between the company-info components.
1. int CGM (AgileInfo ati, StreamWriter out) {
2.
3. String Ticker = this.Input_TickerSymbol; // Get the TICKER symbol.
4.
5. // Instantiate & Initialize the CF
6. AgileTemplate Table = new StockInfoTable(Ticker);
7. // Call the method to generate the AC’s Code
8. Table.CGM(ati, out, 0, 0, null);
9. //Note: The X & Y coordinates may be passed to CGM.
10.
11. // Instantiate & Initialize the CF
12. AgileTemplate Chart1 = new IntraDayChart(Ticker);
13. // Call the method to generate the AC’s Code
14. Chart1.CGM(ati, out, 0, 250, null);
15.
16. // Instantiate & Initialize the CF
17. AgileTemplate Chart2 = new MonthlyChart(Ticker);
18. // Call the method to generate the AC’s Code
19. Chart2.CGM(ati, out, 0, 500, null);
20.
21. }
Note: This also shows a method to build component-hierarchy. The large component contains a Table and two Charts. Likewise, one could build arrays, as shown below:
ComponentFactory CF_Array = {Table, Chart1, Chart2}; //Array of Components
As shown in Fig#2, CF encapsulates the tight coupling of all the Objects and all the logics (e.g. Application, presentation & business logics). It needs just 2 lines of code to include/replace an AC from webpage. If any two ACs needs to collaborate with each other, on average they need no more than 3 to 7 lines of communication code (e.g. to loosely couple service-provider & service-consumer ACs).
Notice, most online-GUI-classes (Navigational-menus, charts and trees etc.) contain in the Agile-Templates library may not be good ‘Component factories’ as per the definition in this document. Most components in the Agile-Templates library (i.e. online-GUI-API) require all the data to be supplied by the developer and do not access data on their own. Developer may use the classes from the GUI library to build his own CF.
The CF usually encloses both business logic and presentation-logic (e.g. one or more GUI-classes). Better designed ‘CF’ could not only ‘highly independent’ but also intelligent to effectively use user profile (client preferences, security/authentication etc.) to build personalized/customized ‘AC’ at real-time. To attain higher lever of Independence, the ‘Component factories’ should require little or no data from callers (or other peer components), except ‘Request’ and ‘Session’ objects; which may contain information about requesting browser, client-profile and/or database-connections etc.
If many such well designed ‘CF’ are available, they can be assembled to build JSP/Servlet for each page in hours and complex web-application in mater of days; or each new CF can be integrated in to any web-application in mater of minutes.
Please remember that, each ‘CF’ may use other ‘CF’ in the same way to build sub-ACs at run-time. For Example, in the Fig#3 example, the ‘CF’ for stock-quote may use other ‘CFs’, (each CF creates SVG-Charts respectively for 1Mont, 3Months, 6Months and 1Year etc.), and select one or more ‘sub-CFs’ by using simple ‘if-then-else’ statement at run-time as per user preferences.
Pseudo Code Sample listing#3
// One may use if-then-else to dynamically select a subcomponent.
AgileTemplate Chart2 = null;
If (user_preference == 1month)
Chart2 = new StockMonthlyChart(Ticker);
else If (user_preference == quterly)
Chart2 = new StockQuterlyChart(Ticker);
else If (user_prefers_half_year)
Chart2 = new StockHalfyearlyChart(Ticker);
else
Chart2 = new StockYearlyChart (Ticker);
// Call the method to generate the code for the sub Application Component.
Chart2.CGM(ati, out);
// If a user wish to see all three, all the charts can be placed one after the other
Notice the two dimensions of flexibility the application designers have, to build highly customized applications. The first dimension is that it is very easy to build ‘intelligent-CF’, which could get each user profile and build the AC as per his preferences. The second dimension is that: It is simple to create yet another intelligent-CF that could choose, at run-time dynamically, a subset of such intelligent ACs to assemble larger customized AC; as per each user preferences (Ex: Use 3 months or 6 months stock chart) by just using simple if-then-else construct.
The design objective of the “CF” is to encapsulate and hide the manufacturing complexity in an independent module (e.g. Java or C++ class). This would allow any one, who needs the AC can get a ready to integrate AC at real-time custom-built by the intelligent-CF. The Objective of the CF is to emulate the manufacturing process, where manufacturers hide the complexity of the manufacturing and internal complexity of the component. If one uses this component as a subcomponent in a larger component, all he needs to concern about the interfaces needed (e.g. to get its services) to integrate the AC and not much else.
For example, consider the Battery in the Cars: The battery maker encapsulates all the manufacturing and functional complexity in a ' Replaceable-Container' (Please review Appendix-A for the very important concept 'Replaceable-Container'). Note the separation of manufacturing and services. It allows the automakers to only concern about services to assemble a part. Since, the automaker mainly relies on the external service-interfaces, the batter-maker preserves his freedom to innovate, to refine the manufacturing process, improve the performance, services or reduce costs.
The component Factory framework is nothing but, building simple and independent CFs/ACs (Replaceable Containers); and assemble such components hierarchically to build larger and larger CFs, and hence WebPages (or Screens) and finally the Application.
You may picture the process of the creating a JSP/Servlet for a web page is just like typesetting the printing machine by placing a simple call to run each ‘CF’ at appropriate location in the page layout (i.e. screen layout). The ‘CF’ manufacture custom ‘AC’ at real-time and places them at appropriate location in the web page that is under construction for each request from client/browser.
For example, if developer likes to place an AC in a cell of a table, just include the code for the appropriate ‘CF’ in the cell. This code is as simple as including one line of code to instantiate the CF-Object, may be few lines to set data objects (remember, well designed CF might not need this data); and finally one line to invoke the Object’s code generation method. Later, if developer likes to replace the ‘CF’ with another ‘CF’, all he has to do is just replace this few lines of code with call to new ‘CF’ for the new AC. Also, if developer likes to select one of these two ‘CF’ based on user preferences, all he has to do is just use if-then-else construct to select appropriate ‘CF’ to build the custom ‘AC’.
No comments:
Post a Comment