An Object-Oriented View

We now consider how to devise an object-oriented architecture for the designs discussed in the presentation and article.

Combinators Are Good, Types Are Better

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 implementation.

  • 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, ...

Get Beautiful Architecture now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.