We now consider how to devise an object-oriented architecture for the designs discussed in the presentation and article.
So far we have dealt with operations and combinators. Operations will remain; the key step is to discard combinators and replace them with types (or classes—the distinction only arises with genericity as discussed below). This brings a considerable elevation of the level of abstraction:
A combinator describes a specific way of building a new
mechanism from existing ones. The combination is defined in a
rigid way: a
take combination (as in
take 3 apples) associates one quantity
element and one food element. As noted earlier, this is the
mathematical equivalent of defining a structure by its
A class defines a type of objects by listing the applicable features (operations). It provides abstraction in the sense of abstract data types: the rest of the world knows the corresponding objects solely through the applicable operations, not from how they were constructed. We may capture these principles of data abstraction and object-oriented design by noting that the approach means knowing objects not from what they are but through what they have (their public features and the associated contracts). This also opens the way to taxonomies of types, or inheritance, to keep the complexity of the model under control and take advantage of commonalities.
By moving from the first approach to the second one, ...