Although we formally call it a design pattern, a façade is really an aspect of good software design principles. The façade pattern presents a unified and simple interface that hides the complexities of the implementation. In object-oriented programming, the façade pattern provides most users with one façade object that can satisfy most of their requirements. Only advanced users may need to access the objects behind it to carry out tasks for which the façade does not provide methods.

As an example, consider the analyses we perform on a trade object. In addition to booking it, we may want to price it, visualize the output dependencies, compute the Greeks, set status flags to indicate life-cycle transformations, etc. In a trading platform, these actions may take place in different subsystem classes. If the client classes (or programming users) of the trading platform access the subsystem classes directly to carry out these tasks, we get into a messy architecture, as shown in Figure 7.1(a). On the other hand, if we abstract away all the subsystems and expose only a high-level interface to the clients through a trade façade, the whole architecture becomes much more manageable (Figure 7.1(b)).

We implicitly used this pattern in our three-tier architecture presented in the previous chapter as Figure 6.5. We have a trade services layer component, for instance, which abstracts away its database access and other implementation details from the users. (By ‘users’, we mean ...

Get Principles of Quantitative Development now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.