Couple of Basic Differences Between real-software-components and other kinds of so called software components

What is orange Juice? Any kind of juice extracted form Orange fruits. No other kind of juice extracted form any other kind of vegetable (e.g. carat, potato or brinjal) or forest fruit (tomato, dewberry or palm) can be Orange Juice. It is foolish to blindly define juice extracted from potato is a kind of Orange Juice, define juice extracted from tomato is another kind of Orange Juice and juice extracted from dewberry is yet another kind of Orange juice (without ever trying to discover “what is an Orange fruit”).

What is CBD (Component-Based Design)? Any kind of product design that uses components for building a product is CBD. Obviously using fake components can never be CBD, so it is absolutely essential to make sure that the components are not fake, by discovering “what is a component”.

The components are very special kind of parts having very unique and essential characteristics. That is each and every real component uniquely and universally shares certain characteristics. No other kind of part can be a component. No other kind of design can be CBD. That is, using any other kind of part can't be CBD. Hence, it is error to define any other kind of useful parts (either having certain useful properties or conform to a so called component model) is a kind of software components and it is error to define that using any kind of such so called software components is a kind of CBD for software.

Important conditions for real-CBD: (1) Cost of disassembling or reassembling must be less than 3% of the total cost of designing the product as hierarchy of replaceable components (i.e. CBD-structure), and designing and building all the components. (2) Each of the components in the CBD-structure can be redesigned and tested individually either in step-1 or step-3 of CBD-process.

In case of software, any real component must be self-contained and can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component. For example, reusable modules such as each reusable-class for a GUI-component (e.g. line-chart, pie-chart or bar-chart) can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component. But such classes can neither achieve the 1^st condition nor can be replaceable-components. Furthermore, each reusable class is not self-contained, since it requires implementing substantial application logic (e.g. to access and process application data for using the data to construct and configure a singleton object instance of a reusable-class) in order to preset a singleton self-contained component (or SCC). Also the resultant SCC is not replaceable (i.e. can’t be disassembled as a unit), since it requires removing all this spaghetti application logic to effectively remove even such singleton self-contained component.

But each of the RSCC (replaceable self-contained component) in the CBD-structure could be more complex as illustrated in City_GIS application. For example, components such as City_ATC or City_Theaters comprise dozens of GUI-components, where each GUI-component is presented by implementing necessary application logic to access/process application data for using the data for initializing and configuring an object instance of respective GUI-classes. The application logic implemented for including each of the GUI-components in a container-RCC (Replaceable Component-Class) for presenting in container-RSCC is generally implemented as a spaghetti code, so no single GUI-component is replaceable individually (i.e. can’t be disassembled as a unit to redesign and test individually, since it requires removing all the associated application logic for effectively removing each of the GUI-components).

Let me define two-kinds of self-contained components (SCCs) (1) singleton-SCC, and (2) compound-SCC, where application code for singleton-SCC uses only one object-instance of a large reusable GUI-class (e.g. for a Pie-chart, Line-chart or a reusable-class for a container GUI-component containing multiple sub-GUI-components) and implements necessary application code for including a SCC, while compound-SCC uses multiple reusable GUI-classes for instantiating multiple object-instances and implements necessary application code for initializing/constructing and configuring each of the object-instances to present multiple GUI-components in a SCC (e.g. City_ATC or City_LandMarks).

Our CBD requires partitioning or identifying SCC in an application and encapsulate all the application code that must be implemented in a RCC (Replaceable Component-Class), so that the SCC can be plugged-in by writing about 3 lines of code (without any need for any additional spaghetti code) and the SCC can be unplugged as a unit (without leaving any traces) by deleting the said 3 lines of code. In conclusion, reusable-classes are not self-contained, but can be used as parts for building SCCs. Our CBD requires making SCCs replaceable, by encapsulating all the application logic implemented for an SCC in a RCC.

Therefore, there are crystal clear differences between reusable-classes (known as reusable components) and RCCs (referred to as replaceable-components or RSCCs) and it is essential to know the clear difference. Since real-software-components are not yet known, today no other GUI-API is designed to encapsulate such large compound-SCC (that uses multiple GUI-classes and also implements necessary application logic for including multiple self-contained GUI-components) in a RCC, which is essential for achieving CBD-structure by building component hierarchies.

One important difference is: The reusable-classes must be generic and flexible (so can’t comprise application specific data/logic) to be reusable in multiple applications, where each application implements application logic to construct and configure using application data to satisfy unique needs of each of the applications. Hence large reusable-classes often can’t be self-contained and not practical to be scaled as possible for compound-RSCC. That is, it is not practical for creating reusable class for City_LandMarks, without making large number of application specific assumptions and without using any application specific data. On the other hand, the RCCs are custom designed for just one target application, hence can comprise 100% of application specific-logic/data and custom designed to not only satisfy current unique needs but also easily adaptable to often unpredictable future evolving needs of the target application.

Today neither singleton-SCCs nor compound-SCCs are designed as RCCs, which proves real-software-components are not yet known. Each reusable-GUI-class for GUI-components (e.g. Pie-chart, bar-chart or a container GUI-component containing multiple sub-GUI-components) are not self-contained, but can be used for including an singleton-SCC in the application (by implementing necessary application logic such as code for accessing and processing application data and using the application data for initializing and configuring an object instance of the reusable-GUI-class for presenting each GUI-component in each container-RSCC).

Is it possible to extract Orange juice from any other kind of fruit or vegetable (by erroneously assuming each kind of fruit or vegetable is a kind of Orange)? Likewise, it is error to assume each kind of parts (either having certain properties or conform to certain so called component models) is a kind of software-components. Using fake software-components is not CBD for software. In case of physical products, we have only few kinds of parts, such as components and ingredient-parts (e.g. steel, silicon, alloys, paint or plastic), since the physical parts are constrained by laws of nature and physical attributes (e.g. size, shape or weight).

The software-parts have no such constraints, so it is possible to invent many kinds of parts for software products, including very unique kind of parts that are logically equivalent to the physical functional-component (by having essential properties uniquely and universally shared by each and every physical functional-component) for achieving real-CBD for software.