Software developers tend to ‘eat the elephant one bite at a time’, splitting complex systems into logical blocks that can be combined in many different ways. As a result, each level is described using applicable terms. This is also an effective way to lower the cohesion between code fragments that represent different operations, and allows them to be changed independently.
This approach results in a large number of design patterns at various levels that describe how data is represented, as well as the algorithms and overall structure of software solutions. These patterns are then applied within software products, allowing them to organize both module interaction and interaction between different software products. In many programming libraries, the API follows some patterns and conditions that make it easier to reuse the code. For example, C++ uses iterators to iterate over a collection of elements, while C# and Java use enumerators. In addition, interprocess interaction systems, such as ActiveX, also allow systems to use these terms, leaving aside the differences in the technologies used.
Some might argue that classical paradigms (e.g. programming without creating complicated user-defined data classes), utilized by the C language and others, can also be used to build an environment for effective code reuse. This is true. However, the number of modern platforms allowing component interaction (e.g. COM, Java, CLR and so on) and using an object-oriented approach suggests that this solution has great potential.
In this sense, opening every component’s API at OS scale seems like the next logical step to improve interaction; a step which, for some reason, has not yet been taken.