|
Hi Folks, Separate content from presentation. [1] That is a design principle which we in the XML community have long espoused.
Today I learned another design principle: implement
mechanism, not policy. [2] Below are my notes on the mechanism-not-policy design principle. How would the design principle be applied to XML? /Roger Design Principle: Mechanism, Not Policy
Policy tends to have a short lifetime, mechanism a long one.
To create code that endures, implement mechanism, not policy. Policy versus Mechanism, Example #1
The following example illustrates the difference between policy and mechanism: [3] An office has several employees. The office has this policy: All employees need to be authenticated
before entering the office. The policy describes what needs to be done without specifying
how it can be achieved. The policy could be enforced by one or more of the following
mechanisms: 1.
RFID reader. 2.
Retina/fingerprint scanner.
Employees working in group A should have access
to area X only between 9 AM and 5 PM. Decoupling the mechanism implementation from the policy specification makes it possible for different applications to use the same mechanism implementation with different policies. This means that those mechanisms are likely to better meet
the needs of a wider range of users, for a longer period of time. Hardwiring policy and mechanism together has two bad effects:
(a)
It makes policy rigid and harder to change in response to user requirements.
(b)
Trying to change policy has a strong tendency to destabilize the mechanisms.
By separating mechanism and policy, it is possible to experiment with new policies without breaking mechanisms. We can also test the mechanism independently and thoroughly. Policy versus Mechanism, Example #2
Here’s another example to illustrate the difference between policy and mechanism: [4] The X windowing system strives to provide “mechanism, not policy”, supporting an extremely general set of graphics operations and deferring decisions about toolkits and interface look-and-feel (the policy) up to the application level
(final choices about behavior are pushed as far toward the user as possible). [1]
https://en.wikipedia.org/wiki/Separation_of_presentation_and_content [2]
http://www.catb.org/esr/writings/taoup/html/ch01s04.html [3] This example comes from:
https://sites.google.com/site/mylokesh/policyvsmechanism [4] This example comes from:
http://www.catb.org/esr/writings/taoup/html/ch01s04.html |
