Policy And Mechanism

Is this supposed to be the pattern "SeparatePolicyFromMechanism?"?

Mechanism is the concrete algorithms, data structures, etc. that get work done. Policy is supposed to be higher level, and use mechanism. You are likely to want to change them independently of each other. So, separate them.

Does anybody have any examples of this?

Constraints vs transaction, except that's kinda backwards

Is this more like the BridgePattern or the StrategyPattern? Or are those just specializations of this general case?

The canonical example of this is the X Windows system [XwindowProtocol]. When X was first developed, "mechanism, not policy" was a common mantra.

On one level, it was a success. X has a highly modular architecture which has withstood numerous changes over the years.

On another level, it was a disaster. While there is nothing wrong per se with decoupling policy from mechanism (and lots of advantages); policy decisions were made in the wrong place. Rather than being something that users, system integrators, or system administrators were given control over; for much of the early history of X application developers were in charge of implementing policy for many things. (Some things were left to window managers or the .Xdefaults file; but many things were handled by the application).

The result was a smorgasboard of applications that a) each worked differently; b) didn't work together, and c) were all butt-UgLy to boot. Application programmers are not UI designers; the fact that they were burdened with look-and-feel issues was a colossal mistake with X.

The good news is that this mistake is (mostly) rectified. Most users of X do so via either KDE or Gnome WindowManagers (though there are a few remaining "session managers are for wimps" cowboys out there, and numerous legacy apps that don't play nice with either environment); and application programmers now can be concerned with what their programs do and not how they look. Still, X-based environments aren't quite as seamless (in 2004) as MicrosoftWindows or MacOs is--fortunately, this is a tractable problem. (And it's more of a personnel/"management" issue than a technical issue anyway.)

X Windows unfortunately gave "SeparateMechanismFromPolicy?" a bad name. The principle says that mechanism and policy should be provided in separate layers, it does not say that you should leave applications to simply do their own thing. Applications are usually the wrong layer to implement policy in; instead, there should be a standardized and well-designed set of policy components for applications to choose between.

I thought the lesson from X window was that applications shouldn't be allowed to choose between anything? Agreed on the separate layer thing.

[That's a popular opinion in some quarters, especially Mac fans who believe in absolute consistency, but on the other hand note that X11 WindowManagers are applications, and they started out very low quality originally, but some have evolved to be much higher quality now.]

[Therefore I took the overall lesson to be that there should at least be a reasonable stab at a default policy; X11's notion of separating mechanism and policy was great in many ways, but then, rather than simply allowing change of policy, they effectively forced everyone to implement policy. No default policy. That sucked. Better would be to have at least one default; people argue about whether there should be more than that or not.]

[BTW, since I mentioned "consistency" in UIs: it has been pointed out that people usually assume consistency is the same as uniformity in UIs, but many times they are not, and also that people usually assume that it's obvious and objective as to what constitutes consistency in UIs, but it turns out to frequently be subjective and ill-defined. So some suggest using different and more specific terminology to avoid miscommunication.]

This topic sorely needs examples.

I agree... this page needs reworking. Anyhow, one example aiming to achieve SeparatePolicyFromMechanism? is ResumableException.

MechanismRichPolicyFree