Most software design processes subdivide a large system into many subsystems or “parts”, in order to build each part autonomously and compose the parts to build fully functional system. Hence, any large system usually comprise of many “parts” (e.g. Objects in the OOP or the “AC” in our CBSDF). The large subsystems are further subdivide into subcomponents, and so on.

As we know, in most systems, each part or component needs to collaborate with one or more other parts. This forces us to create coupling (or dependency) between them, so that they can collaborate with each other. For example, in an automobile, the CD-player needs power, which is a real dependency. We resolve that dependency by connecting the CD-player to the 12V DC car battery. Here the 12V DC is a predefined standardized interface, which is an artificial dependency.

Likewise, two components in an application need to collaborate usually by exchanging data. The data exchange is real dependency. Also the data must be in a predetermined or agreed upon form (e.g. a Data-structure, Object or an XML Schema), in order to understand and properly consume the data. The data must conform to a predefined format to be useful, which is an artificial dependency. Hence, both (i.e. real and artificial) are rational dependencies.

In an ideal component based system, the developer must be concerned with only rational-dependencies, for example, to remove, replace or refine a component. An ideal framework must have simple processes for the designers to partition the system into loosely coupled components, which have only rational dependencies (i.e. real and artificial dependencies). Such dependencies can be simple to find, maintain and update, for example, to remove or replace a component. Also, software vendors could sell tools and processes, which automate: finding and resolving the dependencies etc.

However, applications developed using traditional paradigms, such as the OOP, forces us to spend lot of time resolving irrational dependencies, which exists even between two objects that do not collaborate or exchange data. There is no process to rationalize the dependencies, hence it is very complex to find and resolve all the dependencies, during update or maintenance cycles of the system.

Consider a large Book-library: we catalog and index the books, so that we can find them easily. Looking through the index/catalog, to find a book is a rational-dependency. However, if the books are not organized and have no catalog, searching entire library is an irrational-dependency. Also, if we break apart each book (e.g. component) into many chapters (e.g. Objects) and spread in many floors of the library building, it would be definitely categorized as gross irrational process.

Unfortunately, the OOP process creates grossly irrational dependencies (Also notice  Fig#5). The objects used to build each functional component, are usually spread across many files and mixed with the objects of other components. Hence, it is very hard to rationalize the dependencies between the components. Furthermore, a large functional component may contain many subcomponents, which are spread across many files and mixed with subcomponents of other components. Hence, we are breaking each large book (i.e. a component, which could be encapsulated into a single physical swappable module) into many parts (i.e. chapters or sections) and spread them across many floors in the library (and no useful indexing to find them).

Note: One of the influential paper "No silver bullet", says the complexity is essence of the software and removing the complexity removes the essence of the software. We respectfully disagree and offer a proof  to clearly show that there is a "Silver Bullet". The complexity of finding all Shakespearean works in the above unorganized Book library is "Essential" or "Accidental". Does any attempt to remove the complexity (e.g. by using computers for indexing and organizing) for quickly finding his works remove essence in the Shakespearean works?

Likewise, the CBSDF just organizes the code into hierarchies of replaceable loosely-coupled components as shown in Fig#3. This organization help developers to find dependencies of each and every part accurately and readily. Otherwise isn't it like finding few needles in a haystack? How does the organization of code into hierarchies of replaceable components remove 'essence' from the application?

Accurately: Finding all the dependencies without misses or slipups through cracks
Readily: Finding them with in few minutes without any trial and error (or guesswork)

Also review an example for CF-Component Factory and pictorial over view of CBSDF. Our ambition is to eliminate even the couple of lines of dependency for each CF!

Note: Please recall the figures for the Rational-Dependencies (figure#6, Fig#8) and the Irrational-Dependencies (Fig#5 and Fig#7) in one of the previous web page: Component level abstraction Verses Object level abstraction. Most large applications contain hundreds of components (e.g. hundred times Figure#7); just imagine the ill-cataloged and not-indexed random (i.e. irrational) dependencies of the vast network of tangled spaghetti code.

Software developers are drowning in the sea of irrational dependencies. We (software engineers) are quickly lost in the complex tangled maze of spaghetti code, which is resulting from the irrational dependencies.

What a Tangled Web we weave........?

Pioneer-soft strongly believes that, "Raju's Component Process" (or "RCP") can eliminate one of the biggest causes for the “Software Crisis (Useful proof)” by eliminating the tangled web of irrational dependencies.

Note: Some one might argue that the OOP allows application to partition into parts and the parts are further subdivided into sub-parts and so on. Of course it may be 'virtually' true, but OOP do not offer a "Unified Handle" to each container-part, as computer parts such as hard-drive, CD-drive or Graphics card does. The partitioning of the Objects is only ‘virtual’. As you can see, most large parts (or sub-system) use many Objects, hence it takes considerable effort to find all the Objects, their numerous dependencies, which require painstaking error prone steps to chip away each of the Objects. The RCP physically encapsulates the subcomponents (even large sub-systems containing many parts), which can be referenced through a variable.

If there is no "unified handle" for the Loosely coupled components (Fig#3, Fig#4), the tightly coupled parts (i.e. Objects) of each component (Fig#6, Fig#8) are mixed and spread all over (in many source files as in Fig#5, Fig#7). This forces us to understand and track the interactions between large number of tightly coupled Objects of many components. The irrational dependencies between objects across component boundaries offer no advantage, except adding complexity.