|
Unix Programming - Basics of the Unix Philosophy - Rule of Separation: Separate policy from mechanism;
Rule of Separation: Separate policy from mechanism;
separate interfaces from engines.
In our discussion of what Unix gets wrong, we observed that the
designers of X made a basic decision to implement
“mechanism, not policy”—to make X a generic
graphics engine and leave decisions about user-interface style to
toolkits and other levels of the system. We justified this by
pointing out that policy and mechanism tend to mutate on different
timescales, with policy changing much faster than mechanism. Fashions
in the look and feel of GUI toolkits may come and go, but raster
operations and compositing are forever.
Thus, hardwiring policy and mechanism together has two bad
effects: It makes policy rigid and harder to change in response to user
requirements, and it means that trying to change policy has a strong
tendency to destabilize the mechanisms.
On the other hand, by separating the two we make it possible to
experiment with new policy without breaking mechanisms. We also make
it much easier to write good tests for the mechanism (policy,
because it ages so quickly, often does not justify the investment).
This design rule has wide application outside the GUI
context. In general, it implies that we should look for ways to
separate interfaces from engines.
One way to effect that separation is, for example, to write
your application as a library of C service routines that are driven by an
embedded scripting language, with the application flow of control
written in the scripting language rather thanC. Aclassic example of
this pattern is the Emacs editor, which uses
an embedded Lisp interpreter to control editing
primitives written in C. We discuss this style of design in Chapter11.
Another way is to separate your application into cooperating
front-end and back-end processes communicating through a specialized
application protocol over sockets; we discuss this kind of design in Chapter5 and Chapter7. The front end implements policy; the
back end, mechanism. The global complexity of the pair will often be
far lower than that of a single-process monolith implementing the same
functions, reducing your vulnerability to bugs and lowering life-cycle
costs.
[an error occurred while processing this directive]
|
