Encapsulation of Components in a Replaceable-Container

The “Component Factory” (or CF) may be designed using Object-Oriented programming (OOP) to generate the Application-Component ('AC'). As shown in the Fig below, the CF may use reusable (e.g. COTS: ”Commercial Off The Shelf”) or pre-built GUI-Classes to present parts of the AC; and other objects, such as, DB-objects or EJB-objects to get the necessary data to generate custom AC for each user.

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?

In the OOP, most objects are treated as components. However, CBSDF treats many objects as tools or ingredients to make ideal software component (Important definition). The reusable GUI-API objects, data objects, user-object and plumbing or house keeping Objects are just used to build a fully functional AC (an ready-to-assemble easily replaceable Lego-block). The CBSDF clearly distinguishes between the manufacturing and the custom built AC (a fully manufactured ideal component), which has simple “loosely coupled” service-interfaces to get services at run-time.

Most of the Objects (e.g. forging molds, drills or lathe machine) used to make each part stays at the manufacturing floor and would never end up in the automobile-hood. In the traditional OOP, however, all this tangled Object interactions (manufacturing process shown at top-part in the above Fig) for all the ACs end up in the code for the application (e.g. VisualBasic, Java/Swing or VC++).

CF physically encapsulated all this messy tightly-coupled interactions in a Java-class/Object and CF spits out an AC. This AC (a Lego-block) can be thrown in to the webpage/application file and readily access its services. Each AC may need 5 to 7 lines of simple code to communicate (i.e. to access its services). The class code of the CF can be independent and may be used as a building block in larger CF, and so on.

On the other hand, the OOP treats all the manufacturing-interactions (that are shown using arrows on the top part of above Fig, inside the CF) between the Objects "as integration code". The CBSDF partitions the 'integration-code' into two types:

1. Object-integration code: These tightly-coupled Object interactions to manufacture each of the 'loosely coupled' component may be about 50% of the total CF code. Hence the effective spaghetti integration code in the large OOP applications is nearly 50% of the total application code. This manufacturing need to be performed only one time, during the initialization of the application.

2. Component-integration code : Average code needed to access the services of each AC is about 1% (i.e. about 5 lines to loosely couple each AC) at run-time. Hence the effective Component-integration code is about 1% of the code (if the application is created by hierarchically assembling loosely-coupled replaceable parts). Please notice the red-arrows in the figure below.

In CBSDF, this 1% code is the entire link each AC (or CF) has with rest of the Application. Deleting this 1% code should effectively removes the whole AC/CF from the Application (or separates the CF to refine/update it independently).

The Object-integration code is encapsulated in a smaller easy to separate CF-class. If we need to redesign the AC, we need to comprehend the few lines of Object-integration code within the CF-Class (independently in full isolation).

Hence, the CBSDF breaks the application into many easy to plug-in ACs, wherein the ACs and their loosely coupled service-oriented interfaces can cut the component replacement complexity for large components by about 95% (By cutting the real-coupling or "effective-integration code" from about 50% to about 1% of the total application code).

In the CBSDF, one don't need to worry about the Object-integration shown in the top-part of the first figure to replace the part. In the OOP, for large components, it is often NOT possible to encapsulate them in a replaceable-container (e.g. in a Class-definition or File). So developers are forced to scatter the Objects and chunks of application-logic across many files and mix with the code-chunks (i.e. references to the Objects and application-logic) for other ACs. Hence, he must remove multiple Objects and code-chucks for application-logic from many files to remove the component. To remove each of the Objects, he must comprehend all the Object's dependencies (as explained in Fig#4 and Fig#5 shown in the webpage).

Note: Please visualize this in the context of a very large application (having hundreds of such large components) and container components having few subcomponents (e.g. AC-05 or AC-07 in Fig#3). Is it hard to see the value, if one could remove any component by removing about 5 lines. This would be valuable tool, since even a new recruits could safely interchange any large components (which is practically impossible today). Ask a friend to randomly pick large components in your GUI application, and see how many of them could be replaced by replacing 9 lines or less? Furthermore, automated CASE-tools can detect any broken dependencies (i.e. service-interfaces between the components).

Important Note: One must study the manufacturing history to appreciate the implications of invention of “loosely coupled interchangeable software parts”. One must comprehend, how the invention of interchangeable parts led to the invention of moving assembly line and together responsible for increasing the manufacturing productivity over 100 folds. If you cannot comprehend how the invention of "interchangeable parts" shaped the manufacturing, all our discussion of how to create "loosely coupled software Lego-blocks" and automated mechanisms to assemble them might feel like boring lessons and useless exercise.

The CBSDF introduces a new concept of AC (e.g. loosely coupled components), which neither exists nor makes much difference in the traditional OOP process (since the Objects and their interactions cannot be encapsulated in a replaceable container). For example, in the OOP, some of the Objects must be included in a code-chunk or file, while other objects (e.g. DB, EJB etc.) and the code for the callbacks of the GUI, cannot be keep in the same location or file. This forces developers to split the whole code for each AC into many code-chunks, and scatter them in many files/locations.

These code-chunks (i.e. references to the Objects & application-logic) are spread across many files and mixed with the code-chunks for the other ACs, which makes it impractical to track all the code-chunks. So, it is impossible to create and maintain each AC as an independent replaceable module in the OOP. An Ideal component framework must provide a way to build each component independently at a different location from the assembly line and integrate or just “plug-in” the AC by just using its simple service interfaces.

Define What Constitutes a Real Software Component (Click here)

An Example

Please consider the Battery in the Automobile: The battery maker encapsulates all the manufacturing process, internal interactions and functional complexity in a 'Replaceable-Container'. Notice the separation of manufacturing and services. It allows the automakers/mechanics to only concern about, how to access its services (e.g. connect two wires to get 12VDC or to recharge). The mechanic don’t care about the internal chemical interactions between led & acid (e.g. Objects) to produce the power (or to store the power). This separation also allow the battery-maker to preserve his freedom to innovate, to refine the design and manufacturing process to improve the performance (e.g. lifetime and quality of services) and reduce his making costs.

The design of the “CF” in-effect emulates this. The CF-Class hides the manufacturing and internal functional complexity in an independent easy-to-replace module (e.g. Java class). This allow any one to use the intelligent-CF-Class and get a custom-built easy to assemble and replaceable AC at real-time. If one uses this component as a subcomponent in a larger component, all he needs to concern about is the simple loosely-coupled interfaces (e.g. to get its services) to couple/integrate the AC and not much else.

The component Factory framework is nothing but, building smaller and independent CFs/ACs (Replaceable Containers); and assemble such components hierarchically to build larger and larger ACs, and hence WebPages (or Screens) and finally the Application (a set of Screens/Windows). Please click here and here to understand the CBSDF processes. Please click here and here for sample CFs.