Component Orientation

Software designers often think of large units as components, and claim to be following the example of Doug McIlroy [4]. Yet he was actually a proponent of the idea that small components should be developed (his example was a sine routine) as separate units, which could have a variety of implementations. The model he had in mind was the way that electronics component manufacturers developed and sold individual logic units such as NAND and NOR gates. Such manufacturers at that time published catalogues of their wares, providing specifications describing their exact properties. That model is no longer quite as actual as it was at the time of McIlroy's proposal, since today no-one builds computers from individually purchased NAND and NOR gates.

Perhaps it could likewise be argued that it makes no sense to use a model for developing software based on small components. However that overlooks a significant difference between the development of hardware and software. Electronics engineers first mastered the art of developing small components and then used this knowledge as they progressed to ever larger scale integration, e.g. for entire computer processors and huge electronic memory devices. In contrast, software engineers cannot claim to have mastered the design and development of small components as a starting point for integrating these into large software systems! If anyone needs evidence of this they need only think of the chaos – and the huge software costs – which happened towards the end of the last century as a result of the date problem! This arose, at least in part, because programmers gave little thought to the humble date, and did not incorporate into their programs a standard date component. If such a component had existed (and its interface standardised according to the information hiding principle) it would have been a trivial matter to ensure that it coped correctly with the turn of the century.

Timor makes no logical distinction between large components and small components: they are all defined as types and can have multiple implementations. It should be just as easy, using McIlroy's paradigm, to go to a software components house (not a conventional software house which provides custom systems) and buy an implementation of a (preferably standardised) type Date, and then replace this later with a more efficient or improved implementation, without needing to change the software which uses it.

It is our hope that Timor will encourage the emergence of such software component houses. Without the existence of stable and high quality small components it is impossible really to build stable and high quality large components and even less, entire systems. Therefore we have paid special attention in the Timor design to ensuring that components (of all sizes) can be separately designed and implemented and can be fitted together just as easily as Lego bricks. One of the implications of this is that flexible techniques should be made available for structuring components to serve different purposes, but without compromising any of the principles discussed so far, especially not the principle that all components are defined as types which can have multiple implementations in strict accordance with the information hiding principle